Support riscv64gc-unknown-linux-gnu target

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?

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.

@mati865

@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.

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.

@mati865

@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).

@Disasm

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

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

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?

@laanwj

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

@sanxiyn

@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.

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.

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

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

@tblah

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

@kinnison

@kinnison what is 1.22?

@tshepang

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

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.

@tblah

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.

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`

@infinity0

@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

@infinity0

@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.

@msizanoen1

@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.

@infinity0

@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

@tblah

@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.

@infinity0

@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

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

Navigation Menu

Repository navigation

Support riscv64gc-unknown-linux-gnu target #62117

42 remaining items

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Support riscv64gc-unknown-linux-gnu target #62117

Description

Activity

mati865 commented on Jun 26, 2019

fintelia commented on Jun 26, 2019

mati865 commented on Jun 26, 2019

Disasm commented on Jun 29, 2019

mati865 commented on Jun 29, 2019

davidlt commented on Sep 26, 2019

laanwj commented on Sep 28, 2019

sanxiyn commented on Oct 5, 2019

laanwj commented on Oct 5, 2019

archshift commented on Nov 5, 2019

msizanoen1 commented on Nov 25, 2019

42 remaining items

tblah commented on Jun 2, 2020

kinnison commented on Jun 3, 2020

tshepang commented on Jun 3, 2020

kinnison commented on Jun 3, 2020

infinity0 commented on Jul 26, 2020

msizanoen1 commented on Jul 27, 2020

msizanoen1 commented on Jul 27, 2020

msizanoen1 commented on Jul 27, 2020

msizanoen1 commented on Jul 27, 2020

infinity0 commented on Jul 27, 2020

tblah commented on Aug 2, 2020

infinity0 commented on Aug 14, 2020

tblah commented on Aug 15, 2020

Kreijstal commented on Jan 10, 2024

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions