Support riscv64gc-unknown-linux-gnu target #62117

fintelia · 2019-06-25T14:58:44Z

It was recently pointed out that Rust is one of the main blockers for the Debian RISC-V port. I wanted to ask what is actually missing on the Rust side? Since there is already support for the equivalent bare metal targets, is it simply a matter of porting the standard library? How much work would that actually be?

mati865 · 2019-06-26T07:25:31Z

I can try building it but I won't be able to test it on real hardware.
One of issues for Debian would be LLVM. If they want to use system LLVM 8 they would need many backports for it.

EDIT: Failed with LLVM ERROR: Unable to lowerGlobalAddress, probably this should just wait until Rust rebases to LLVM 9.

fintelia · 2019-06-26T14:34:01Z

@mati865 Could you clarify what you tried? The riscv64imac-unknown-none-elf and similar targets do work but do have some issues. They also rely on some relatively recent upstream commits, so I won't expect them to work with any system LLVM yet.

mati865 · 2019-06-26T15:32:59Z

I added new target riscv64gc-uknown-linux-gnu and tried to cross compile for it but hit LLVM ERROR: Unable to lowerGlobalAddress during stage1. With static relocation model it went further to stage2 and failed at libc, will be on my TODO.

AFAK Debian has strict packaging policy and packages must use system libraries.

Disasm · 2019-06-29T08:14:20Z

@mati865

Failed with LLVM ERROR: Unable to lowerGlobalAddress

This is already fixed in LLVM upstream master, but not released. At the moment I'm trying to grab some commits from master to fix this for riscv64*-unknown-none-elf targets. However, iirc for -linux- targets you also need TLS support (which is also in master, but not released).

mati865 · 2019-06-29T08:49:42Z

@Disasm thanks. I haven't got that far yet to run executables. I'm waiting for #61393 anyway.

davidlt · 2019-09-26T09:51:11Z

Seems that Rust moved to LLVM 9.0.0 which has support for riscv64 (not experimental anymore). Thus targeting Linux should be possible now.

laanwj · 2019-09-28T12:28:46Z

Great progress! Does that mean it's possible to compile rust code for the hard-float (lp64d) ABI? Will the riscv64gc-none- target be changed to this too?

sanxiyn · 2019-10-05T02:20:46Z

@laanwj, hard-float is a separate issue, see #65024.

laanwj · 2019-10-05T09:20:42Z

@sanxiyn Thanks! Yes, I only mentioned it in this context because the existing gcc Linux riscv64gc target uses hardfloat, at least on Fedora Linux RISC-V, so it seems it's a requirement.

archshift · 2019-11-05T23:59:41Z

Matching what I mentioned in #65024, it is now at least possible to write a riscv64gc-unknown-linux target specification file with a hard-float ABI. The next step would probably be to port libc then.

msizanoen1 · 2019-11-25T05:10:48Z

See #66661. In the meantime you can use https://github.com/msizanoen1/rust-riscv.

msizanoen1 · 2019-11-25T05:13:22Z

Also the RISC-V backend in LLVM 9.0 is even stable enough to compile rustc.

msizanoen1 · 2019-11-28T10:49:58Z

RISC-V support has landed in libc master, waiting on a new libc release.

msizanoen1 · 2019-11-30T12:19:27Z

#66899

msizanoen1 · 2019-12-01T09:01:25Z

Compiling rustc for riscv64 also needs this: rust-lang/llvm-project#29

msizanoen1 · 2019-12-01T14:54:55Z

I have successfully compiled rustc using the combined patches:

sirius@localhost:~/rust-rv$ file bin/rustc
bin/rustc: ELF 64-bit LSB pie executable, UCB RISC-V, version 1 (SYSV), dynamically linked, interpreter /lib/ld-linux-riscv64-lp64d.so.1, for GNU/Linux 4.15.0, with debug_info, not stripped
sirius@localhost:~/rust-rv$ qemu-riscv64 ./bin/rustc -Vv
rustc 1.41.0-nightly (930a0a2d0 2019-12-01)
binary: rustc
commit-hash: 930a0a2d0b9966b276de49e7a865186152c2f075
commit-date: 2019-12-01
host: riscv64gc-unknown-linux-gnu
release: 1.41.0-nightly
LLVM version: 9.0
sirius@localhost:~/rust-rv$ qemu-riscv64 ./bin/rustc -C linker=riscv64-unknown-linux-gnu-gcc -C opt-level=3 ~/hello.rs
sirius@localhost:~/rust-rv$ file ./hello
./hello: ELF 64-bit LSB pie executable, UCB RISC-V, version 1 (SYSV), dynamically linked, interpreter /lib/ld-linux-riscv64-lp64d.so.1, for GNU/Linux 4.15.0, with debug_info, not stripped
sirius@localhost:~/rust-rv$ qemu-riscv64 ./hello
Hello, world!

Binaries for anyone wants to try on real hardware/emulator: https://github.com/msizanoen1/rust-binaries/releases/tag/riscv
If you have real hardware, you should try using it to compile programs like ripgrep, fd, etc. to uncover any possible bugs.

infinity0 · 2020-01-04T04:28:17Z

Testing this for Debian's rustc now. Thanks for all the work!

List of PRs backported to 1.40.0:

Allow specifying LLVM's MCTargetOptions::ABIName in target specification files #65953
Add riscv64gc-unknown-linux-gnu target #66661
part of formatting-only PR Format libstd/os with rustfmt #66818
part of formatting-only PR Format libstd with rustfmt #66820
Standard library support for riscv64gc-unknown-linux-gnu #66899
Support for RISC-V 64-bit GNU/Linux libc#1606
Add RISC-V support cc-rs#428
risc-v: Set ABI correctly for 32-bit targets cc-rs#429
risc-v: Disable PIC by default for now cc-rs#430
Default to double-float ABI on RISC-V Linux cc-rs#460
Enable -fPIC on non-bare-metal RISC-V cc-rs#461
Add cross prefix for riscv64gc-unknown-linux-gnu => riscv64-linux-gnu cc-rs#465 (edit: added later)
Recognise riscv64 in compiletest #68006 (edit: added later)

infinity0 · 2020-01-04T05:04:54Z

One last thing, for cross-compiling support we need to add this to the cc crate:

                        "riscv64gc-unknown-linux-gnu" => Some("riscv64-linux-gnu"),

otherwise the build fails with:

CC_riscv64gc-unknown-linux-gnu = Some("cc")
[..]
cargo:warning=cc: error: unrecognized argument in option ‘-mabi=lp64d’
cargo:warning=cc: note: valid arguments to ‘-mabi=’ are: ms sysv

I will file a PR to the cc crate shortly.

infinity0 · 2020-01-04T11:55:54Z

After also adding

Add cross prefix for riscv64gc-unknown-linux-gnu => riscv64-linux-gnu cc-rs#465

in additional to the patches above, I now have some Debian rustc riscv64 packages:

-rw-rw-r--  1  12637740 Jan  4 07:06 libstd-rust-1.40-dbgsym_1.40.0+dfsg1-4_riscv64.deb
-rw-rw-r--  1  13068220 Jan  4 07:06 libstd-rust-1.40_1.40.0+dfsg1-4_riscv64.deb
-rw-rw-r--  1  20587812 Jan  4 07:06 libstd-rust-dev_1.40.0+dfsg1-4_riscv64.deb
-rw-rw-r--  1   3555180 Jan  4 07:06 rustc-dbgsym_1.40.0+dfsg1-4_riscv64.deb
-rw-rw-r--  1   2917812 Jan  4 07:06 rustc_1.40.0+dfsg1-4_riscv64.deb

https://people.debian.org/~infinity0/rust/riscv64/

infinity0 · 2020-01-06T13:33:50Z

@msizanoen1 did you try cargo? It builds but then the tests fail for us, due to some rustc ICEs (terminate called after throwing an instance of 'std::bad_alloc')

failures:

---- build_script::output_shows_on_vv stdout ----
running `/<<PKGBUILDDIR>>/target/riscv64gc-unknown-linux-gnu/debug/cargo build -vv`
thread 'build_script::output_shows_on_vv' panicked at '
Expected: execs
    but: exited with exit code: 101
--- stdout

--- stderr
   Compiling foo v0.5.0 (/<<PKGBUILDDIR>>/target/riscv64gc-unknown-linux-gnu/cit/t361/foo)
     Running `CARGO_PKG_AUTHORS= CARGO_PKG_DESCRIPTION= CARGO_PKG_REPOSITORY= CARGO_PKG_NAME=foo CARGO=/<<PKGBUILDDIR>>/target/riscv64gc-unknown-linux-gnu/debug/cargo CARGO_PKG_HOMEPAGE= CARGO_PKG_VERSION_MAJOR=0 CARGO_PKG_VERSION_PRE= CARGO_PKG_VERSION_MINOR=5 CARGO_PKG_VERSION_PATCH=0 CARGO_MANIFEST_DIR=/<<PKGBUILDDIR>>/target/riscv64gc-unknown-linux-gnu/cit/t361/foo LD_LIBRARY_PATH='/<<PKGBUILDDIR>>/target/riscv64gc-unknown-linux-gnu/cit/t361/foo/target/debug/deps:/usr/lib:/<<PKGBUILDDIR>>/target/riscv64gc-unknown-linux-gnu/debug/deps:/<<PKGBUILDDIR>>/target/riscv64gc-unknown-linux-gnu/debug:/usr/lib/rustlib/riscv64gc-unknown-linux-gnu/lib' CARGO_PKG_VERSION=0.5.0 rustc --crate-name build_script_build build.rs --color never --crate-type bin --emit=dep-info,link -C debuginfo=2 -C metadata=60011d13829a7254 -C extra-filename=-60011d13829a7254 --out-dir /<<PKGBUILDDIR>>/target/riscv64gc-unknown-linux-gnu/cit/t361/foo/target/debug/build/foo-60011d13829a7254 -L dependency=/<<PKGBUILDDIR>>/target/riscv64gc-unknown-linux-gnu/cit/t361/foo/target/debug/deps`
terminate called after throwing an instance of 'std::bad_alloc'
  what():  std::bad_alloc
error: could not compile `foo`.

Caused by:
  process didn't exit successfully: `CARGO_PKG_AUTHORS= CARGO_PKG_DESCRIPTION= CARGO_PKG_REPOSITORY= CARGO_PKG_NAME=foo CARGO=/<<PKGBUILDDIR>>/target/riscv64gc-unknown-linux-gnu/debug/cargo CARGO_PKG_HOMEPAGE= CARGO_PKG_VERSION_MAJOR=0 CARGO_PKG_VERSION_PRE= CARGO_PKG_VERSION_MINOR=5 CARGO_PKG_VERSION_PATCH=0 CARGO_MANIFEST_DIR=/<<PKGBUILDDIR>>/target/riscv64gc-unknown-linux-gnu/cit/t361/foo LD_LIBRARY_PATH='/<<PKGBUILDDIR>>/target/riscv64gc-unknown-linux-gnu/cit/t361/foo/target/debug/deps:/usr/lib:/<<PKGBUILDDIR>>/target/riscv64gc-unknown-linux-gnu/debug/deps:/<<PKGBUILDDIR>>/target/riscv64gc-unknown-linux-gnu/debug:/usr/lib/rustlib/riscv64gc-unknown-linux-gnu/lib' CARGO_PKG_VERSION=0.5.0 rustc --crate-name build_script_build build.rs --color never --crate-type bin --emit=dep-info,link -C debuginfo=2 -C metadata=60011d13829a7254 -C extra-filename=-60011d13829a7254 --out-dir /<<PKGBUILDDIR>>/target/riscv64gc-unknown-linux-gnu/cit/t361/foo/target/debug/build/foo-60011d13829a7254 -L dependency=/<<PKGBUILDDIR>>/target/riscv64gc-unknown-linux-gnu/cit/t361/foo/target/debug/deps` (signal: 6, SIGABRT: process abort signal)
', crates/cargo-test-support/src/lib.rs:846:13
stack backtrace:
   0: <std::sys_common::backtrace::_print::DisplayBacktrace as core::fmt::Display>::fmt
   1: core::fmt::write
   2: std::io::Write::write_fmt
   3: std::io::impls::<impl std::io::Write for alloc::boxed::Box<W>>::write_fmt
   4: std::panicking::default_hook::{{closure}}
   5: std::panicking::default_hook
   6: std::panicking::rust_panic_with_hook
   7: std::panicking::continue_panic_fmt
   8: std::panicking::begin_panic_fmt
   9: cargo_test_support::Execs::run
             at crates/cargo-test-support/src/lib.rs:846
  10: testsuite::build_script::output_shows_on_vv
             at tests/testsuite/build_script.rs:3133
  11: testsuite::build_script::output_shows_on_vv::{{closure}}
             at tests/testsuite/build_script.rs:3106
  12: core::ops::function::FnOnce::call_once
             at /usr/src/rustc-1.40.0/src/libcore/ops/function.rs:227
  13: <alloc::boxed::Box<F> as core::ops::function::FnOnce<A>>::call_once
  14: __rust_maybe_catch_panic
  15: test::run_test_in_process
note: Some details are omitted, run with `RUST_BACKTRACE=full` for a verbose backtrace.

---- freshness::changing_bin_paths_common_target_features_caches_targets stdout ----
running `/<<PKGBUILDDIR>>/target/riscv64gc-unknown-linux-gnu/debug/cargo run`
running `/<<PKGBUILDDIR>>/target/riscv64gc-unknown-linux-gnu/debug/cargo clean -p a`
running `/<<PKGBUILDDIR>>/target/riscv64gc-unknown-linux-gnu/debug/cargo run`
running `/<<PKGBUILDDIR>>/target/riscv64gc-unknown-linux-gnu/debug/cargo run`
thread 'freshness::changing_bin_paths_common_target_features_caches_targets' panicked at '
Expected: execs
    but: exited with exit code: 101
--- stdout

--- stderr
   Compiling dep_crate v0.0.1 (/<<PKGBUILDDIR>>/target/riscv64gc-unknown-linux-gnu/cit/t694/foo/dep_crate)
   Compiling b v0.0.1 (/<<PKGBUILDDIR>>/target/riscv64gc-unknown-linux-gnu/cit/t694/foo/b)
terminate called after throwing an instance of 'std::bad_alloc'
  what():  std::bad_alloc
error: could not compile `b`.

Caused by:
  process didn't exit successfully: `rustc --crate-name b src/main.rs --color never --crate-type bin --emit=dep-info,link -C debuginfo=2 -C metadata=3b59d81b677ca06d -C extra-filename=-3b59d81b677ca06d --out-dir /<<PKGBUILDDIR>>/target/riscv64gc-unknown-linux-gnu/cit/t694/foo/./target/debug/deps -L dependency=/<<PKGBUILDDIR>>/target/riscv64gc-unknown-linux-gnu/cit/t694/foo/./target/debug/deps --extern b=/<<PKGBUILDDIR>>/target/riscv64gc-unknown-linux-gnu/cit/t694/foo/./target/debug/deps/libb-ee9c889405ac4542.rlib --extern dep_crate=/<<PKGBUILDDIR>>/target/riscv64gc-unknown-linux-gnu/cit/t694/foo/./target/debug/deps/libdep_crate-6f56469f09f33530.rlib` (signal: 6, SIGABRT: process abort signal)
', crates/cargo-test-support/src/lib.rs:846:13
stack backtrace:
   0: <std::sys_common::backtrace::_print::DisplayBacktrace as core::fmt::Display>::fmt
   1: core::fmt::write
   2: std::io::Write::write_fmt
   3: std::io::impls::<impl std::io::Write for alloc::boxed::Box<W>>::write_fmt
   4: std::panicking::default_hook::{{closure}}
   5: std::panicking::default_hook
   6: std::panicking::rust_panic_with_hook
   7: std::panicking::continue_panic_fmt
   8: std::panicking::begin_panic_fmt
   9: cargo_test_support::Execs::run
             at crates/cargo-test-support/src/lib.rs:846
  10: testsuite::freshness::changing_bin_paths_common_target_features_caches_targets
             at tests/testsuite/freshness.rs:369
  11: testsuite::freshness::changing_bin_paths_common_target_features_caches_targets::{{closure}}
             at tests/testsuite/freshness.rs:257
  12: core::ops::function::FnOnce::call_once
             at /usr/src/rustc-1.40.0/src/libcore/ops/function.rs:227
  13: <alloc::boxed::Box<F> as core::ops::function::FnOnce<A>>::call_once
  14: __rust_maybe_catch_panic
  15: test::run_test_in_process
note: Some details are omitted, run with `RUST_BACKTRACE=full` for a verbose backtrace.

---- rustc::build_main_and_allow_unstable_options stdout ----
running `/<<PKGBUILDDIR>>/target/riscv64gc-unknown-linux-gnu/debug/cargo rustc -v --bin foo -- -C debug-assertions`
thread 'rustc::build_main_and_allow_unstable_options' panicked at '
Expected: execs
    but: exited with exit code: 101
--- stdout

--- stderr
   Compiling foo v0.0.1 (/<<PKGBUILDDIR>>/target/riscv64gc-unknown-linux-gnu/cit/t1365/foo)
     Running `rustc --crate-name foo src/lib.rs --color never --crate-type lib --emit=dep-info,metadata,link -C debuginfo=2 -C metadata=6e264f0333de7585 -C extra-filename=-6e264f0333de7585 --out-dir /<<PKGBUILDDIR>>/target/riscv64gc-unknown-linux-gnu/cit/t1365/foo/target/debug/deps -L dependency=/<<PKGBUILDDIR>>/target/riscv64gc-unknown-linux-gnu/cit/t1365/foo/target/debug/deps`
     Running `rustc --crate-name foo src/main.rs --color never --crate-type bin --emit=dep-info,link -C debuginfo=2 -C debug-assertions -C metadata=57a025506b93114d -C extra-filename=-57a025506b93114d --out-dir /<<PKGBUILDDIR>>/target/riscv64gc-unknown-linux-gnu/cit/t1365/foo/target/debug/deps -L dependency=/<<PKGBUILDDIR>>/target/riscv64gc-unknown-linux-gnu/cit/t1365/foo/target/debug/deps --extern foo=/<<PKGBUILDDIR>>/target/riscv64gc-unknown-linux-gnu/cit/t1365/foo/target/debug/deps/libfoo-6e264f0333de7585.rlib`
terminate called after throwing an instance of 'std::bad_alloc'
  what():  std::bad_alloc
error: could not compile `foo`.

Caused by:
  process didn't exit successfully: `rustc --crate-name foo src/main.rs --color never --crate-type bin --emit=dep-info,link -C debuginfo=2 -C debug-assertions -C metadata=57a025506b93114d -C extra-filename=-57a025506b93114d --out-dir /<<PKGBUILDDIR>>/target/riscv64gc-unknown-linux-gnu/cit/t1365/foo/target/debug/deps -L dependency=/<<PKGBUILDDIR>>/target/riscv64gc-unknown-linux-gnu/cit/t1365/foo/target/debug/deps --extern foo=/<<PKGBUILDDIR>>/target/riscv64gc-unknown-linux-gnu/cit/t1365/foo/target/debug/deps/libfoo-6e264f0333de7585.rlib` (signal: 6, SIGABRT: process abort signal)
', crates/cargo-test-support/src/lib.rs:846:13
stack backtrace:
   0: <std::sys_common::backtrace::_print::DisplayBacktrace as core::fmt::Display>::fmt
   1: core::fmt::write
   2: std::io::Write::write_fmt
   3: std::io::impls::<impl std::io::Write for alloc::boxed::Box<W>>::write_fmt
   4: std::panicking::default_hook::{{closure}}
   5: std::panicking::default_hook
   6: std::panicking::rust_panic_with_hook
   7: std::panicking::continue_panic_fmt
   8: std::panicking::begin_panic_fmt
   9: cargo_test_support::Execs::run
             at crates/cargo-test-support/src/lib.rs:846
  10: testsuite::rustc::build_main_and_allow_unstable_options
             at tests/testsuite/rustc.rs:59
  11: testsuite::rustc::build_main_and_allow_unstable_options::{{closure}}
             at tests/testsuite/rustc.rs:52
  12: core::ops::function::FnOnce::call_once
             at /usr/src/rustc-1.40.0/src/libcore/ops/function.rs:227
  13: <alloc::boxed::Box<F> as core::ops::function::FnOnce<A>>::call_once
  14: __rust_maybe_catch_panic
  15: test::run_test_in_process
note: Some details are omitted, run with `RUST_BACKTRACE=full` for a verbose backtrace.


failures:
    build_script::output_shows_on_vv
    freshness::changing_bin_paths_common_target_features_caches_targets
    rustc::build_main_and_allow_unstable_options

test result: FAILED. 1648 passed; 3 failed; 0 ignored; 0 measured; 0 filtered out

infinity0 · 2020-01-06T16:04:59Z

@msizanoen1 no worries, that one was on QEMU, we tried again on real riscv64 hardware and it worked OK including tests.

Looks like everything works!

davidlt · 2020-01-06T17:04:03Z

Does this mean we get the official support starting 1.41.0 release?

mati865 · 2020-01-06T17:27:09Z

@davidlt definitely not sooner than 1.42.

infinity0 · 2020-01-08T21:18:47Z

If you have Debian Unstable on riscv64 you should be able to apt install rustc since about 2 days ago. Some more rust programs have been built, others are being built.

infinity0 · 2020-01-09T02:33:39Z

These packages fail to build only on riscv64. They look fixable to someone familiar with how riscv64 should work.

We also had segfaults in gtk-sys, proptest, and data-encoding-macro on actual riscv64 hardware, I've mentioned this to the Debian riscv64 people. Bear in mind this is riscv64 patches backported to rustc 1.40.0, so there is a small chance I might have missed something, but several hundred other rust crates built OK & some even ran their tests successfully.

fintelia · 2020-01-09T05:25:31Z

rust-nodrop-union seems to just require the unions_with_drop_fields feature (the compiler warns that it doesn't recognize the feature name, and then errors out saying that unions can't have drop fields). Was it added very recently?

A few others also seem to just be version disagreements about what constants and such can be imported.

infinity0 · 2020-03-08T21:31:50Z

I'm unaware if there are any specific instructions but you can add extra foreign architectures to the host and target keys in config.toml when building rustc itself, like any other foreign architecture. See config.toml.example for an example.

infinity0 · 2020-04-04T11:53:24Z

@msizanoen1 1.41 is failing in Debian because of fatal error: gnu/stubs-lp64.h: No such file or directory, I am told that the cc crate needs updating:

<aurel32> infinity0: it seems that rustc wrongly use the lp64 abi instead of the lp64d ABI
<aurel32> look at the content of stubs.h: http://paste.debian.net/1138383/
<aurel32> so clearly the files are built with the softfloat abi instead of the hardfloat one
<aurel32> i have no idea why though
<aurel32> well because the call to cc has "-mabi=lp64" instead of "-mabi=lp64d" or nothing (at it's the default)
<infinity0> ah right, so we'll need to patch the cc crate probably
<aurel32> in vendor/cc/src/lib.rs: // ABI is always soft-float right now, update this when this is no longer the
<aurel32>  // case:
<aurel32> i guess that comes from there

infinity0 · 2020-04-04T12:01:27Z

Never mind, this was just because we dropped rust-lang/cc-rs#460 by mistake when doing an update.

tblah · 2020-04-27T16:20:36Z

What is blocking this issue?

tommythorn · 2020-04-27T16:51:31Z

rustup support is pending a built risc-v toolchain: rust-lang/rustup#2296 (comment)

tblah · 2020-04-28T14:33:05Z

@tommythorn platforms need tier 2 support for officially released binaries to be built for rustup.

The rules or tier 2 support are such that there must be a team of developers willing to maintain that architecture.

I volunteer for that role, but I'm no team on my own, and I'm lacking in expertise. Would anybody else be interested?

mati865 · 2020-04-28T23:15:00Z

Are there available reasonably priced RISC-V boards capable to run full Linux distro and Rust?
I'm interested in helping but that would be hard without real hardware.

tommythorn · 2020-04-28T23:41:23Z

Why would you need real hardware? Considering that most software development is run and tested with qemu and with the current state of affairs are far easier to use that the available (expensive) hardware solutions. Running Ubuntu 20.04 is this easy:

$ wget https://github.com/carlosedp/riscv-bringup/releases/download/v1.0/UbuntuFocal-riscv64-QemuVM.tar.gz
$ tar xzf UbuntuFocal-riscv64-QemuVM.tar.gz
$ ./run_riscvVM.sh

OpenSBI v0.6
   ____                    _____ ____ _____
  / __ \                  / ____|  _ \_   _|
 | |  | |_ __   ___ _ __ | (___ | |_) || |
 | |  | | '_ \ / _ \ '_ \ \___ \|  _ < | |
 | |__| | |_) |  __/ | | |____) | |_) || |_
  \____/| .__/ \___|_| |_|_____/|____/_____|
        | |
        |_|
.......
[  OK  ] Reached target Login Prompts.

Ubuntu 20.04 LTS Ubuntu-riscv64 ttyS0

Ubuntu-riscv64 login: root
Password: riscv
Welcome to Ubuntu 20.04 LTS (GNU/Linux 5.5.0-dirty riscv64)

 * Documentation:  https://help.ubuntu.com
 * Management:     https://landscape.canonical.com
 * Support:        https://ubuntu.com/advantage

Last login: Wed Apr  1 17:24:16 UTC 2020 on ttyS0
            .-/+oossssoo+/-.               root@Ubuntu-riscv64 
        `:+ssssssssssssssssss+:`           ------------------- 
      -+ssssssssssssssssssyyssss+-         OS: Ubuntu 20.04 LTS focal riscv64 
    .ossssssssssssssssssdMMMNysssso.       Host: riscv-virtio,qemu 
   /ssssssssssshdmmNNmmyNMMMMhssssss/      Kernel: 5.5.0-dirty 
  +ssssssssshmydMMMMMMMNddddyssssssss+     Uptime: 1 min 
 /sssssssshNMMMyhhyyyyhmNMMMNhssssssss/    Shell: bash 5.0.16 
.ssssssssdMMMNhsssssssssshNMMMdssssssss.   Terminal: /dev/ttyS0 
+sssshhhyNMMNyssssssssssssyNMMMysssssss+   CPU: (4) 
ossyNMMMNyMMhsssssssssssssshmmmhssssssso   Memory: 61MiB / 3948MiB 
ossyNMMMNyMMhsssssssssssssshmmmhssssssso
+sssshhhyNMMNyssssssssssssyNMMMysssssss+                           
.ssssssssdMMMNhsssssssssshNMMMdssssssss.                           
 /sssssssshNMMMyhhyyyyhdNMMMNhssssssss/
  +sssssssssdmydMMMMMMMMddddyssssssss+
   /ssssssssssshdmNNNNmyNMMMMhssssss/
    .ossssssssssssssssssdMMMNysssso.
      -+sssssssssssssssssyyyssss+-
        `:+ssssssssssssssssss+:`
            .-/+oossssoo+/-.

root@Ubuntu-riscv64:~# apt install rustc
Reading package lists... Done
Building dependency tree       
Reading state information... Done
The following additional packages will be installed:
  binutils binutils-common binutils-riscv64-linux-gnu ca-certificates cargo
  cpp cpp-9 gcc gcc-9 gcc-9-base gdb libasn1-8-heimdal libatomic1
  libbabeltrace1 libbinutils libbrotli1 libc-dev-bin libc6-dbg libc6-dev
  libcc1-0 libcrypt-dev libctf-nobfd0 libctf0 libcurl3-gnutls libdw1
...

provided you have a sufficiently new QEMU installed.

mati865 · 2020-04-29T00:24:17Z

@tommythorn I've hard hard time testing specific app on AArch64 (this one was confirmed as QEMU bug) and RISC-V QEMU few months ago. Since then I usually prefer to work with real hardware.
But yeah, I see that QEMU 5.0 has already been uploaded to test repo so I'm going to play with it this/next week.

programmerjake · 2020-04-29T04:20:42Z

@mati865 we're currently working on designing a fully open-source SoC with OpenPower/RISC-V/GPU hybrid processors, once they come out there should be inexpensive raspberry pi-like boards available (guessing around $25), you should be able to do all the needed testing/development on them (except for supervisor mode -- that's Power-only though emulation should be possible). We're getting the first engineering sample chips in october!

davidlt · 2020-04-29T06:34:19Z

You want to test on QEMU and real physical hardware (e.g. SiFive HiFive Unleashed, https://www.crowdsupply.com/sifive/hifive-unleashed , sadly not more available).

QEMU 4.2.0 had FP bug that caused issues in Linux (e.g. SSH wouldn't work properly) and FU540 SoC in Unleahed have TLB flush errata. TLB flush issue was fixed recently (few months ago?) in OpenSBI (one of firmware components). For example this TLB flush errata caused Golang bootstrap segfaults.

I highly advice to test QEMU and physical hardware as bugs could exist in both. Most of distributions are built with QEMU VMs or/and a mix of VMs and Unleashed boards.

I high end PC/workstation with high clocks would most likely outperform Unleashed board. You can go up to 8 cores on QEMU which helps.

All major distributions (Fedora, Debian, SUSE and now even Ubuntu) have something available in one form or another.

413: Add riscv64gc-unknown-linux-gnu support r=reitermarkus a=tblah rust support for riscv64gc-unknown-linux-gnu [is not yet advertised](https://forge.rust-lang.org/release/platform-support.html), but [is merged](rust-lang/rust#66661). There are [issues](rust-lang/rust#62117) with riscv64gc-unknown-linux-gnu but it works well enough to build many crates (including rustc). Co-authored-by: Tom Eccles <tom.eccles@codethink.co.uk>

tblah · 2020-06-02T16:48:45Z

In case anybody missed it, riscv64gc-unknown-linux-gnu is now tier 2
rust-lang/rust-forge#356

kinnison · 2020-06-03T13:27:05Z

I have merged stable support for this platform in our CI. If everything goes well, 1.22 will quietly release with riscv support, though I'll need @tblah to test it during the prerelease sequence :D

tshepang · 2020-06-03T13:41:40Z

@kinnison what is 1.22?

kinnison · 2020-06-03T13:46:17Z

@tshepang The next rustup release, when I get to it.

infinity0 · 2020-07-26T19:06:29Z

Has anyone tried a native build, compiling rustc on riscv64 without cross-compiling? Our builds still consistently fail for various different reasons, but occasionally succeed on real hardware - rv-mullvad-*, rv-rr44-*, are HiFive; whereas rr-mit-* are QEMU.

msizanoen1 · 2020-07-27T01:44:22Z

From https://www.codethink.co.uk/articles/2020/fixing-rusts-test-suite-on-risc-v (by @tblah):

In the last blog post I mentioned an issue where some rustc tests would hang indefinitely. While I was tracking down the problem, the upstream Rust project upgraded from LLVM 9 to LLVM 10, which fixed the hanging tests. I did not look into this issue further.

And from the build logs for 1.43:

test [ui] ui/wait-forked-but-failed-child.rs ...
test [ui] ui/wait-forked-but-failed-child.rs has been running for over 60 seconds
test [ui] ui/wrapping-int-combinations.rs ...
test [ui] ui/wrapping-int-combinations.rs has been running for over 60 seconds
test [ui] ui/wrapping-int-combinations.rs ... ok
E: Build killed with signal TERM after 150 minutes of inactivity

So a way to ensure that the test suite runs successfully is to upgrade rustc to a version that supports LLVM 10 and upgrade the LLVM version used in rustc in Debian to LLVM 10.

msizanoen1 · 2020-07-27T02:04:30Z

For version 1.44 in experimental:

     Running `/<<PKGBUILDDIR>>/build/riscv64gc-unknown-linux-gnu/stage1-rustc/release/build/libc-45f75b95dbdb835c/build-script-build`                 
error: failed to run custom build command for `libc v0.2.69`
                                                                                          
Caused by:                                        
  could not execute process `/<<PKGBUILDDIR>>/build/riscv64gc-unknown-linux-gnu/stage1-rustc/release/build/libc-45f75b95dbdb835c/build-script-build` (never executed)
                                                                                     
Caused by:                                        
  No such file or directory (os error 2)          
warning: build failed, waiting for other jobs to finish...

And:

error[E0412]: cannot find type `AtomicU128` in module `atomic`                                          
    --> /usr/src/rustc-1.44.1/vendor/crossbeam-utils/src/atomic/atomic_cell.rs:541:32                    
     |                                            
541  |   impl_arithmetic!(u128, atomic::AtomicU128, "let a = AtomicCell::new(7u128);");                  
     |                                  ^^^^^^^^^^
 help: a struct with a similar name exists: `AtomicU16`

msizanoen1 · 2020-07-27T02:26:45Z

@infinity0 Version 1.47 (current nightly) and later is guaranteed to build as RISC-V GNU/Linux 64-bit has been added to CI: #72973

msizanoen1 · 2020-07-27T02:46:50Z

@infinity0 From the logs above for crossbeam-utils it seems like it has been misconfigured to use certain atomic types even when these types does not exist for RISC-V.

infinity0 · 2020-07-27T12:42:28Z

@msizanoen1 Thanks for taking a look, I am in the process of updating to 1.45 with LLVM 10 in Debian. The crossbeam issue was caused by #74803 and appeared on all architectures, however an earlier error in that log that is riscv64-specific is for libcore:

Did not run successfully: Ok(ExitStatus(ExitStatus(11)))
"/<<PKGBUILDDIR>>/build/riscv64gc-unknown-linux-gnu/stage1/bin/rustc" "--crate-name" "core" "--edition=2018" "src/libcore/lib.rs" "--error-format=json" "--json=diagnostic-rendered-ansi,artifacts" "--crate-type" "lib" "--emit=dep-info,metadata,link" "-C" "opt-level=3" "-C" "metadata=bd79c7b65dc84d34" "-C" "extra-filename=-bd79c7b65dc84d34" "--out-dir" "/<<PKGBUILDDIR>>/build/riscv64gc-unknown-linux-gnu/stage1-std/riscv64gc-unknown-linux-gnu/release/deps" "--target" "riscv64gc-unknown-linux-gnu" "-C" "linker=riscv64-linux-gnu-gcc" "-L" "dependency=/<<PKGBUILDDIR>>/build/riscv64gc-unknown-linux-gnu/stage1-std/riscv64gc-unknown-linux-gnu/release/deps" "-L" "dependency=/<<PKGBUILDDIR>>/build/riscv64gc-unknown-linux-gnu/stage1-std/release/deps" "-C" "link-args=-Wl,-z,relro" "--cap-lints" "warn" "--remap-path-prefix=/<<PKGBUILDDIR>>=/usr/src/rustc-1.44.1" "-Zmacro-backtrace" "-Wrust_2018_idioms" "-Wunused_lifetimes" "-Dwarnings" "-Cprefer-dynamic" "-Zbinary-dep-depinfo" "--sysroot" "/<<PKGBUILDDIR>>/build/riscv64gc-unknown-linux-gnu/stage1" "-C" "debug-assertions=n" "-Z" "force-unstable-if-unmarked"

exit-status 11 looks like maybe a segfault, I haven't been able to look into it in more detail yet. edit: most likely a segfault, #74832 makes it a bit obscure.

tblah · 2020-08-02T10:10:05Z

@infinity0 sorry for taking so long to get back to you. I wanted to at least reproduce the issue and come back with something concrete but I am having some trouble.

~~On my machine just the LLVM build under QEMU is taking several days so I have not been able to reproduce your issue yet. I see your builds completed after a few hours. My machine isn't that slow.~~

~~What QEMU version and configuration are you using?~~

Edit: I've reproduced the problem on rust a99ae95 (with minor alterations) with LLVM 10 and normal versions of all dependencies. Thanks for reporting the issue @infinity0

infinity0 · 2020-08-14T22:44:45Z

@tblah how did you reproduce it? It seems the upgrade to LLVM 10 made things work for us now, we have green builds (native riscv64->riscv64 build) for 1.45.0 and 1.46.0 beta.

tblah · 2020-08-15T07:24:49Z

@infinity0 ./x.py build worked okay for me but if I tried anything else (e.g. rustfmt) it would fail with the same error you had: things like

error[E0463]: can't find crate for `core`
error[E0463]: can't find crate for `std`

I will try 1.46.0

Kreijstal · 2024-01-10T11:04:29Z

very surprised to have rust work in my riscv computer flawlessly, thank you

jonas-schievink added C-feature-request Category: A feature request, i.e: not implemented / a PR. O-linux Operating system: Linux O-riscv Target: RISC-V architecture T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. labels Jun 25, 2019

tblah mentioned this issue Apr 24, 2020

Add riscv64gc-unknown-linux-gnu support cross-rs/cross#413

Merged

tommythorn mentioned this issue Apr 27, 2020

RISC-V support? rust-lang/rustup#2296

Closed

tblah mentioned this issue Apr 28, 2020

platform-support: add tier3 riscv64gc-unknown-linux-gnu rust-lang/rust-forge#343

Merged

kinnison closed this as completed Jun 3, 2020

Support riscv64gc-unknown-linux-gnu target #62117

Support riscv64gc-unknown-linux-gnu target #62117

Comments

fintelia commented Jun 25, 2019

mati865 commented Jun 26, 2019 • edited

fintelia commented Jun 26, 2019

mati865 commented Jun 26, 2019

Disasm commented Jun 29, 2019

mati865 commented Jun 29, 2019

davidlt commented Sep 26, 2019

laanwj commented Sep 28, 2019

sanxiyn commented Oct 5, 2019

laanwj commented Oct 5, 2019

archshift commented Nov 5, 2019

msizanoen1 commented Nov 25, 2019

msizanoen1 commented Nov 25, 2019

msizanoen1 commented Nov 28, 2019

msizanoen1 commented Nov 30, 2019

msizanoen1 commented Dec 1, 2019

msizanoen1 commented Dec 1, 2019 • edited

infinity0 commented Jan 4, 2020 • edited

infinity0 commented Jan 4, 2020

infinity0 commented Jan 4, 2020

infinity0 commented Jan 6, 2020 • edited

infinity0 commented Jan 6, 2020

davidlt commented Jan 6, 2020

mati865 commented Jan 6, 2020

infinity0 commented Jan 8, 2020

infinity0 commented Jan 9, 2020 • edited

fintelia commented Jan 9, 2020 • edited

infinity0 commented Mar 8, 2020 • edited

infinity0 commented Apr 4, 2020

infinity0 commented Apr 4, 2020

tblah commented Apr 27, 2020

tommythorn commented Apr 27, 2020

tblah commented Apr 28, 2020

mati865 commented Apr 28, 2020

tommythorn commented Apr 28, 2020 • edited

mati865 commented Apr 29, 2020

programmerjake commented Apr 29, 2020

davidlt commented Apr 29, 2020

tblah commented Jun 2, 2020

kinnison commented Jun 3, 2020

tshepang commented Jun 3, 2020

kinnison commented Jun 3, 2020

infinity0 commented Jul 26, 2020 • edited

msizanoen1 commented Jul 27, 2020 • edited

msizanoen1 commented Jul 27, 2020 • edited

msizanoen1 commented Jul 27, 2020

msizanoen1 commented Jul 27, 2020

infinity0 commented Jul 27, 2020 • edited

tblah commented Aug 2, 2020 • edited

infinity0 commented Aug 14, 2020

tblah commented Aug 15, 2020

Kreijstal commented Jan 10, 2024

mati865 commented Jun 26, 2019 •

edited

msizanoen1 commented Dec 1, 2019 •

edited

infinity0 commented Jan 4, 2020 •

edited

infinity0 commented Jan 6, 2020 •

edited

infinity0 commented Jan 9, 2020 •

edited

fintelia commented Jan 9, 2020 •

edited

infinity0 commented Mar 8, 2020 •

edited

tommythorn commented Apr 28, 2020 •

edited

infinity0 commented Jul 26, 2020 •

edited

msizanoen1 commented Jul 27, 2020 •

edited

msizanoen1 commented Jul 27, 2020 •

edited

infinity0 commented Jul 27, 2020 •

edited

tblah commented Aug 2, 2020 •

edited