RISCV Arch Support

[dvc94ch]

Tracking issue for riscv support:

riscv-rust-toolchain

llvm and rustc

these are likely not going to get done for Epoch 2018 release:

• [x] llvm upstreaming (wip, asb is working on this)

• [x] rustc upstreaming (I don't need cabi support at the moment, and likely easier to get done once llvm upstream can build libcore)

• [ ] port to riscv32-unknown-linux-gnu (waiting on better atomic support in llvm)

• [ ] get compiler test suite to run on riscv backend (waiting on riscv32-unknown-linux-gnu port)

---

embedded rust

tasks for Epoch 2018:

• [x] svd2rust upstreaming (not much to do here, the missing svd features are supported in recent svd2rust, https://github.com/japaric/svd2rust/pull/185)
• [x] split hifive crate into e310-hal and hifive crates, update to latest embedded-hal
• [ ] cross docker image for quick setup (related to #43 https://github.com/japaric/cross/pull/131)

[thejpster]

I just wanted to add - that's amazing!!

[dvc94ch]

Is there a secret to backtraces in rust?

(gdb) bt
#0  riscv_rt::lang_items::panic_fmt ()
    at /home/dvc/repos/riscv-rust/crates/riscv-rt/src/lang_items.rs:10
#1  0x20400e80 in core::panicking::panic_fmt (fmt=..., file_line_col=<optimized out>)
    at /home/dvc/repos/riscv-rust/rust/src/libcore/panicking.rs:71
Backtrace stopped: frame did not save the PC

This is what I have in my Cargo.toml:

# Also see target file riscv32-unknown-none.json
# and .cargo/config for other options required to
# build riscv32 binaries.
[profile.release]
opt-level = 1
debug = true
debug-assertions = true

[profile.dev]
opt-level = 1
debug = true
debug-assertions = true

[japaric]

@dvc94ch That should Just Work if LLVM is doing the right wrt emitting debuginfo / DWARF. Maybe RISCV debuginfo support is not complete or buggy?

Some ideas:

Any chance you could test this with clang? If you do and get something better then this might be a rustc (i.e. frontend) bug. (seems unlikely to me; AFAIK we do nothing arch specific about debuginfo).

You could try compiling with opt-level = 0, which is the dev profile default value; optimization tends to degrade debuginfo (specially the source map info, due to inlining), but I never seen that "frame did not save the PC" error message when debugging (embedded) Rust code.

Finally, does backtrace work in other contexts? Panicking uses the C ABI so your cabi stuff could be incorrect and the culprit for this.

[dvc94ch]

Still debugging this problem, this is what I wrote to the riscv ml, in case someone has any input on the rust side of things...

I don't think the frame handling code sets appropriate metadata on spill slots currently. If gdb is trying to use dwarf metadata rather than simple frame unwinding, I could imagine unexpected issues.

I'm having some trouble implementing this feature correctly. When should there be a .debug_frame and when a .eh_frame section?

My work in progress patch emits a .debug_frame section when all functions are @nounwind and an .eh_frame section if any function does not have @nounwind. This seems to me like desired behavior.

Rust when compiling with panic=abort declares @nounwind on all rust functions unless extern "C" is used to declare it. This leads rust libraries compiled with an extern "C" to have a .eh_frame section and rust libraries containing no extern "C" to have a .debug_frame section. I'm not sure if this is desired behaviour.

rustc doesn't like that very much and when doing -emit=obj of an executable it drops the .eh_frame and .debug_frame sections entirely, before emitting the final object file for linking. This is undesired behavior.

[japaric]

I'm having some trouble implementing this feature correctly. When should there be a .debug_frame and when a .eh_frame section?

My work in progress patch emits a .debug_frame section when all functions are @nounwind and an .eh_frame section if any function does not have @nounwind. This seems to me like desired behavior.

Rust when compiling with panic=abort declares @nounwind on all rust functions unless extern "C" is used to declare it. This leads rust libraries compiled with an extern "C" to have a .eh_frame section and rust libraries containing no extern "C" to have a .debug_frame section. I'm not sure if this is desired behaviour.

rustc doesn't like that very much and when doing -emit=obj of an executable it drops the .eh_frame and .debug_frame sections entirely, before emitting the final object file for linking. This is undesired behavior.

@dvc94ch Sorry, this is beyond my knowledge. Maybe @michaelwoerister or @tromey can give you some pointers; they are most familiar with Rust debuginfo internals.

[dvc94ch]

I'm past this issue, at least in a it works way. I'll be publishing a tutorial and all the code for running rust on the hifive board soon...

[dvc94ch]

Bricked my first hifive board today! Don't mess with the clocks... =P Unless you can disconnect the external flash to halt the cpu.

There is an undocumented safeboot feature.

[dvc94ch]

riscv-rust-toolchain, the crates are still lacking, but from what I can tell the toolchain works pretty well. Let me know if you have any problems with it.

[japaric]

@dvc94ch

svd2rust upstreaming

Do you have a SVD file for the RISC-V micro you are using? I hear from the Ada folks that SiFive is not providing one and that they are writing one manually.

[dvc94ch]

I wrote the one I'm currently using [0] but we should migrate to using these [1]. I'm currently working on another project, will hopefully get back to working on this sometime...

[0] https://github.com/dvc94ch/e310x/blob/master/e310x.svd [1] https://github.com/micro-os-plus/sifive-devices-xpack/tree/xpack/xsvd

[japaric]

@dvc94ch btw, LLVM 6 just landed in rustc and should ship with tomorrow's nightly. Do you know if LLVM 6 has good support for RISC V or if it still needs some patches on top of that? If the former, we could send a PR enabling the LLVM backend to allow experimentation with an out of tree target specification. If the later perhaps the Rust team would be willing accept some backports.

[dvc94ch]

Need to try it to know for sure, but it seems that there isn't much missing. That sounds like a plan...

[dvc94ch]

@japaric Do you think that rust would accept a llvm fork like llvm-emscripten for riscv until llvm7 is released?

[japaric]

@dvc94ch I think that would be a tall order. The Rust team is fine enabling backends that won't impose a heavy maintenance burden. The exception being the emscripten backend, which has been a pain in the neck to maintain, but it's there because of the popularity of asm.js / wasm. I doubt they'll want to maintain a fork with a maintenance burden similar to the emscripten fork. Also, emscripten support will probably be dropped at some point, in favor of the upstream wasm backend.

Is RISCV support in LLVM6 still incomplete? There's the possibility of backporting RISCV patches to LLVM6 but if that's a lot then it may be better to just wait until rustc upgrades to LLVM7? I think that with the wasm momentum and LLD landing in rustc with the explicit goal of linking wasm objects it's likely that LLVM will be upgraded more often (so they can pick up wasm related LLD and backend improvements).

[dvc94ch]

I haven't looked closely at llvm-emscripten, but could we maybe leverage loading llvm at runtime for using it with an independently maintained llvm fork (published via crates.io)? I'm not sure if there is an advantage, since it would be a source build, which is a put-off for most people...

[japaric]

@dvc94ch Yeah, I think we should not have the users build LLVM from source; that's too high a entry barrier.

[glaubitz]

Just curious, how is the progress on this? LLVM seems to have gained riscv64 support already and Debian has been building riscv64 for some weeks now.

[dvc94ch]

That uses the gcc toolchain. That's not too relevant to rust on riscv

[glaubitz]

That uses the gcc toolchain. That's not too relevant to rust on riscv

Yes, I'm aware of that. However, as I said, LLVM has target support for riscv64 already.

See: https://github.com/rust-lang/llvm/tree/9ad4b7e8d7d1618fc9686aa8d3d0b4de3b7a6f36/lib/Target/RISCV

[dvc94ch]

Last time I checked it had RV64I support, a side effect of variable sized registers landing in llvm. I wouldn't call that "support" necessarily...

On Thu, May 31, 2018, 15:30 John Paul Adrian Glaubitz < notifications@github.com> wrote:

That uses the gcc toolchain. That's not too relevant to rust on riscv

Yes, I'm aware of that. However, as I said, LLVM has target support for riscv64 already.

See: https://github.com/rust-lang/llvm/tree/9ad4b7e8d7d1618fc9686aa8d3d0b4de3b7a6f36/lib/Target/RISCV

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/rust-lang-nursery/embedded-wg/issues/36#issuecomment-393530456, or mute the thread https://github.com/notifications/unsubscribe-auth/AAtRr13hKETTRWD8TbgTy-UhDRwW0GDhks5t3_B8gaJpZM4O9aY_ .

[bradjc]

With https://github.com/rust-lang/rust/pull/51966 being merged (update to use LLVM 7 for nightly rust), where does this stand?

[dvc94ch]

Due to working on https://electron-lang.org I haven't kept up to date on recent developments. Building it now, will take a couple of hours...

[dvc94ch]

@bradjc all I can say is that it builds core until https://github.com/japaric/xargo/issues/218 is resolved... @japaric any ideas?

[bradjc]

@dvc94ch can you share a pointer to what you are building?

[dvc94ch]

rust: https://github.com/riscv-rust/rust/commits/riscv-rust-nightly binutils and openocd: https://github.com/riscv-rust/riscv-rust-toolchain riscv-crates: https://github.com/riscv-rust/riscv-crates (pushed some fixes, still got to resolve some linking problems and unresolved memcpy symbol)

[dvc94ch]

Also I'm glad to add people to the riscv-rust org so that I'm not a bottleneck... Let me know if someone is interested.

[bradjc]

I made the following patch to https://github.com/riscv-rust/rust/commits/riscv-rust-nightly

diff --git a/src/bootstrap/sanity.rs b/src/bootstrap/sanity.rs
index c7f514da93..f76d7210b4 100644
--- a/src/bootstrap/sanity.rs
+++ b/src/bootstrap/sanity.rs
@@ -173,7 +173,7 @@ pub fn check(build: &mut Build) {
             panic!("the iOS target is only supported on macOS");
         }

-        if target.contains("-none-") {
+        if target.contains("-none-") || target.ends_with("-none") {
             if build.no_std(*target).is_none() {
                 let target = build.config.target_config.entry(target.clone())
                     .or_insert(Default::default());

because the riscv32ia-unknown-none target ends in -none. Then I could build rust with:

./x.py build
./x.py dist --target x86_64-apple-darwin,riscv32iam-unknown-none

Over in riscv-crates I ran:

rustup toolchain link riscv-rust /Users/bradjc/git/rust/build/x86_64-apple-darwin/stage2/
rustup override set riscv-rust

and made these diffs:

diff --git a/Cargo.toml b/Cargo.toml
index fd7bb0c..a6d2bf1 100644
--- a/Cargo.toml
+++ b/Cargo.toml
@@ -12,7 +12,7 @@ riscv-rt = { path = "riscv-rt" }
 e310x = { path = "e310x" }
 e310x-hal = { path = "e310x-hal" }
 hifive = { path = "hifive" }
-riscv-rtfm = { path = "riscv-rtfm" }
+#riscv-rtfm = { path = "riscv-rtfm" }
 #riscv-alloc = { path = "riscv-alloc" }
 riscv-semihosting = { path = "riscv-semihosting" }
 riscv-rust-quickstart = { path = "riscv-rust-quickstart" }

diff --git a/Makefile b/Makefile
index 7cef932..8c06f40 100644
--- a/Makefile
+++ b/Makefile
@@ -1,5 +1,5 @@
 # Examples (uncomment one)
-#EXAMPLE      := blinky_delay
+EXAMPLE      := blinky_delay
 #EXAMPLE      := blinky_clint
 #EXAMPLE      := blinky_pwm
 #EXAMPLE      := blinky_plic
@@ -8,7 +8,7 @@
 #EXAMPLE      := pll
 #EXAMPLE      := semihosting
 #EXAMPLE      := stlog
-EXAMPLE      := rtfm
+# EXAMPLE      := rtfm
 #EXAMPLE      := static_mut

 # Board crate (uncomment one)
@@ -28,7 +28,7 @@ BAUD_RATE := 115200
 TTY := /dev/ttyUSB2

 build:
-       xargo build --examples $(ARGS)
+       cargo build --examples $(ARGS) --target $(TARGET)

 test:
        xargo test --all $(ARGS)

Then in https://github.com/riscv-rust/riscv-rust-toolchain:

make binutils

and added /Users/bradjc/git/riscv-rust-toolchain/toolchain/bin to my PATH.

Finally, in rustv-crates:

$ make
cargo build --examples  --target riscv32ia-unknown-none
warning: unused manifest key: profile.dev.incremental
warning: unused manifest key: profile.release.incremental
   Compiling riscv-crates v0.1.0 (file:///Users/bradjc/git/riscv-crates)
error: linking with `riscv32-unknown-elf-ld` failed: exit code: 1
  |
  = note: "riscv32-unknown-elf-ld" "-L" "/Users/bradjc/git/rust/build/x86_64-apple-darwin/stage2/lib/rustlib/riscv32ia-unknown-none/lib" "/Users/bradjc/git/riscv-crates/target/riscv32ia-unknown-none/debug/examples/pll-97ae5064c8f9a8c7.pll0.rcgu.o" "-o" "/Users/bradjc/git/riscv-crates/target/riscv32ia-unknown-none/debug/examples/pll-97ae5064c8f9a8c7" "--gc-sections" "-L" "/Users/bradjc/git/riscv-crates/target/riscv32ia-unknown-none/debug/deps" "-L" "/Users/bradjc/git/riscv-crates/target/debug/deps" "-L" "/Users/bradjc/git/riscv-crates/target/riscv32ia-unknown-none/debug/build/riscv-rt-732869a40d34c185/out" "-L" "/Users/bradjc/git/riscv-crates/target/riscv32ia-unknown-none/debug/build/e310x-hal-51d2ac46bf89cbb1/out" "-L" "/Users/bradjc/git/riscv-crates/target/riscv32ia-unknown-none/debug/build/stlog-a77e423998c2d997/out" "-L" "/Users/bradjc/git/rust/build/x86_64-apple-darwin/stage2/lib/rustlib/riscv32ia-unknown-none/lib" "-Bstatic" "/Users/bradjc/git/riscv-crates/target/riscv32ia-unknown-none/debug/deps/libhifive-adb02ffbf3438e5f.rlib" "/Users/bradjc/git/riscv-crates/target/riscv32ia-unknown-none/debug/deps/libe310x_hal-772deef53db13f0c.rlib" "/Users/bradjc/git/riscv-crates/target/riscv32ia-unknown-none/debug/deps/libe310x-b4cdafbfad61b96d.rlib" "/Users/bradjc/git/riscv-crates/target/riscv32ia-unknown-none/debug/deps/libvcell-41df175ff4adf1cb.rlib" "--start-group" "/Users/bradjc/git/riscv-crates/target/riscv32ia-unknown-none/debug/deps/libriscv_rt-5146bd7d0d4567f1.rlib" "/Users/bradjc/git/riscv-crates/target/riscv32ia-unknown-none/debug/deps/libr0-21452b4d2d498389.rlib" "/Users/bradjc/git/riscv-crates/target/riscv32ia-unknown-none/debug/deps/libriscv-83a89d7af68116e2.rlib" "/Users/bradjc/git/riscv-crates/target/riscv32ia-unknown-none/debug/deps/libbare_metal-95599928a420a721.rlib" "/Users/bradjc/git/riscv-crates/target/riscv32ia-unknown-none/debug/deps/libembedded_hal-251a28831585c0aa.rlib" "/Users/bradjc/git/riscv-crates/target/riscv32ia-unknown-none/debug/deps/libnb-f3f365033ce27152.rlib" "/Users/bradjc/git/rust/build/x86_64-apple-darwin/stage2/lib/rustlib/riscv32ia-unknown-none/lib/libcore-12e821654a60cb90.rlib" "--end-group" "/Users/bradjc/git/rust/build/x86_64-apple-darwin/stage2/lib/rustlib/riscv32ia-unknown-none/lib/libcompiler_builtins-d5fed3eea920f53a.rlib" "-Tmemory.x" "-Tlink.x" "-Tstlog.x" "-Bdynamic"
  = note: riscv32-unknown-elf-ld:memory.x:5: warning: redeclaration of memory region `FLASH'
          riscv32-unknown-elf-ld:memory.x:6: warning: redeclaration of memory region `RAM'
          /Users/bradjc/git/rust/build/x86_64-apple-darwin/stage2/lib/rustlib/riscv32ia-unknown-none/lib/libcore-12e821654a60cb90.rlib(core-12e821654a60cb90.core0-26cbe79562c80b0b2f37fb1b31b85748.rs.rcgu.o): In function `core::fmt::num::<impl core::fmt::Display for u32>::fmt':
          /Users/bradjc/git/rust/src/libcore/fmt/num.rs:(.text._ZN4core3fmt3num52_$LT$impl$u20$core..fmt..Display$u20$for$u20$u32$GT$3fmt17hec6bb3533ea710feE+0x88): undefined reference to `__mulsi3'
          /Users/bradjc/git/rust/src/libcore/fmt/num.rs:222: undefined reference to `__mulsi3'
          /Users/bradjc/git/rust/src/libcore/fmt/num.rs:(.text._ZN4core3fmt3num52_$LT$impl$u20$core..fmt..Display$u20$for$u20$u32$GT$3fmt17hec6bb3533ea710feE+0x160): undefined reference to `__mulsi3'
          /Users/bradjc/git/rust/build/x86_64-apple-darwin/stage2/lib/rustlib/riscv32ia-unknown-none/lib/libcore-12e821654a60cb90.rlib(core-12e821654a60cb90.core4-26cbe79562c80b0b2f37fb1b31b85748.rs.rcgu.o): In function `core::slice::<impl [T]>::iter':
          /Users/bradjc/git/rust/src/libcore/slice/mod.rs:591: undefined reference to `__mulsi3'
          /Users/bradjc/git/rust/build/x86_64-apple-darwin/stage2/lib/rustlib/riscv32ia-unknown-none/lib/libcompiler_builtins-d5fed3eea920f53a.rlib(compiler_builtins-d5fed3eea920f53a.compiler_builtins3-e6c7de302c75faff1910af27ace3f090.rs.rcgu.o): In function `core::num::<impl u32>::leading_zeros':
          /Users/bradjc/git/rust/src/libcore/num/mod.rs:2112: undefined reference to `__mulsi3'
          /Users/bradjc/git/rust/build/x86_64-apple-darwin/stage2/lib/rustlib/riscv32ia-unknown-none/lib/libcompiler_builtins-d5fed3eea920f53a.rlib(compiler_builtins-d5fed3eea920f53a.compiler_builtins3-e6c7de302c75faff1910af27ace3f090.rs.rcgu.o):/Users/bradjc/git/rust/src/libcore/num/mod.rs:2112: more undefined references to `__mulsi3' follow

error: linking with `riscv32-unknown-elf-ld` failed: exit code: 1
  |
  = note: "riscv32-unknown-elf-ld" "-L" "/Users/bradjc/git/rust/build/x86_64-apple-darwin/stage2/lib/rustlib/riscv32ia-unknown-none/lib" "/Users/bradjc/git/riscv-crates/target/riscv32ia-unknown-none/debug/examples/hello_world-a81bff85f48f3fff.hello_world0.rcgu.o" "-o" "/Users/bradjc/git/riscv-crates/target/riscv32ia-unknown-none/debug/examples/hello_world-a81bff85f48f3fff" "--gc-sections" "-L" "/Users/bradjc/git/riscv-crates/target/riscv32ia-unknown-none/debug/deps" "-L" "/Users/bradjc/git/riscv-crates/target/debug/deps" "-L" "/Users/bradjc/git/riscv-crates/target/riscv32ia-unknown-none/debug/build/riscv-rt-732869a40d34c185/out" "-L" "/Users/bradjc/git/riscv-crates/target/riscv32ia-unknown-none/debug/build/e310x-hal-51d2ac46bf89cbb1/out" "-L" "/Users/bradjc/git/riscv-crates/target/riscv32ia-unknown-none/debug/build/stlog-a77e423998c2d997/out" "-L" "/Users/bradjc/git/rust/build/x86_64-apple-darwin/stage2/lib/rustlib/riscv32ia-unknown-none/lib" "-Bstatic" "/Users/bradjc/git/riscv-crates/target/riscv32ia-unknown-none/debug/deps/libhifive-adb02ffbf3438e5f.rlib" "/Users/bradjc/git/riscv-crates/target/riscv32ia-unknown-none/debug/deps/libe310x_hal-772deef53db13f0c.rlib" "/Users/bradjc/git/riscv-crates/target/riscv32ia-unknown-none/debug/deps/libe310x-b4cdafbfad61b96d.rlib" "/Users/bradjc/git/riscv-crates/target/riscv32ia-unknown-none/debug/deps/libvcell-41df175ff4adf1cb.rlib" "--start-group" "/Users/bradjc/git/riscv-crates/target/riscv32ia-unknown-none/debug/deps/libriscv_rt-5146bd7d0d4567f1.rlib" "/Users/bradjc/git/riscv-crates/target/riscv32ia-unknown-none/debug/deps/libr0-21452b4d2d498389.rlib" "/Users/bradjc/git/riscv-crates/target/riscv32ia-unknown-none/debug/deps/libriscv-83a89d7af68116e2.rlib" "/Users/bradjc/git/riscv-crates/target/riscv32ia-unknown-none/debug/deps/libbare_metal-95599928a420a721.rlib" "/Users/bradjc/git/riscv-crates/target/riscv32ia-unknown-none/debug/deps/libembedded_hal-251a28831585c0aa.rlib" "/Users/bradjc/git/riscv-crates/target/riscv32ia-unknown-none/debug/deps/libnb-f3f365033ce27152.rlib" "/Users/bradjc/git/rust/build/x86_64-apple-darwin/stage2/lib/rustlib/riscv32ia-unknown-none/lib/libcore-12e821654a60cb90.rlib" "--end-group" "/Users/bradjc/git/rust/build/x86_64-apple-darwin/stage2/lib/rustlib/riscv32ia-unknown-none/lib/libcompiler_builtins-d5fed3eea920f53a.rlib" "-Tmemory.x" "-Tlink.x" "-Tstlog.x" "-Bdynamic"
  = note: riscv32-unknown-elf-ld:memory.x:5: warning: redeclaration of memory region `FLASH'
          riscv32-unknown-elf-ld:memory.x:6: warning: redeclaration of memory region `RAM'
          /Users/bradjc/git/rust/build/x86_64-apple-darwin/stage2/lib/rustlib/riscv32ia-unknown-none/lib/libcore-12e821654a60cb90.rlib(core-12e821654a60cb90.core0-26cbe79562c80b0b2f37fb1b31b85748.rs.rcgu.o): In function `core::fmt::num::<impl core::fmt::Display for u32>::fmt':
          /Users/bradjc/git/rust/src/libcore/fmt/num.rs:(.text._ZN4core3fmt3num52_$LT$impl$u20$core..fmt..Display$u20$for$u20$u32$GT$3fmt17hec6bb3533ea710feE+0x88): undefined reference to `__mulsi3'
          /Users/bradjc/git/rust/src/libcore/fmt/num.rs:222: undefined reference to `__mulsi3'
          /Users/bradjc/git/rust/src/libcore/fmt/num.rs:(.text._ZN4core3fmt3num52_$LT$impl$u20$core..fmt..Display$u20$for$u20$u32$GT$3fmt17hec6bb3533ea710feE+0x160): undefined reference to `__mulsi3'
          /Users/bradjc/git/rust/build/x86_64-apple-darwin/stage2/lib/rustlib/riscv32ia-unknown-none/lib/libcore-12e821654a60cb90.rlib(core-12e821654a60cb90.core4-26cbe79562c80b0b2f37fb1b31b85748.rs.rcgu.o): In function `core::slice::<impl [T]>::iter':
          /Users/bradjc/git/rust/src/libcore/slice/mod.rs:591: undefined reference to `__mulsi3'
          /Users/bradjc/git/rust/build/x86_64-apple-darwin/stage2/lib/rustlib/riscv32ia-unknown-none/lib/libcompiler_builtins-d5fed3eea920f53a.rlib(compiler_builtins-d5fed3eea920f53a.compiler_builtins3-e6c7de302c75faff1910af27ace3f090.rs.rcgu.o): In function `core::num::<impl u32>::leading_zeros':
          /Users/bradjc/git/rust/src/libcore/num/mod.rs:2112: undefined reference to `__mulsi3'
          /Users/bradjc/git/rust/build/x86_64-apple-darwin/stage2/lib/rustlib/riscv32ia-unknown-none/lib/libcompiler_builtins-d5fed3eea920f53a.rlib(compiler_builtins-d5fed3eea920f53a.compiler_builtins3-e6c7de302c75faff1910af27ace3f090.rs.rcgu.o):/Users/bradjc/git/rust/src/libcore/num/mod.rs:2112: more undefined references to `__mulsi3' follow

error: aborting due to previous error

error: aborting due to previous error

error: Could not compile `riscv-crates`.
warning: build failed, waiting for other jobs to finish...
error: Could not compile `riscv-crates`.
warning: build failed, waiting for other jobs to finish...
error: build failed
make: *** [build] Error 101

That's how far I have gotten.

It seems like adding riscv as a target to nightly rust is quite possible right now.

[danc86]

Just FYI __mulsi3 is the software implementation of multiplication for CPUs without a hardware multiplier. If it's trying to link that in, it means Rust thinks your CPU has no multiplication unit. If you add:

 "-C", "target-feature=+m",

to rustflags in the cargo config, this link error should go away. Of course someone may still want to target CPUs without a multiplier in which case they will need __mulsi3 so there is still a real bug here.

[bradjc]

That flag is already there:

https://github.com/riscv-rust/riscv-crates/blob/38008c4dd7ea2a5712dfd12b6bfc9d00ea2c4b21/.cargo/config#L8

and I verified that it is included in the rustc command.

rustc --crate-name hello_world examples/hello_world.rs --crate-type bin --emit=dep-info,link -C codegen-units=1 -C debuginfo=2 -C metadata=a81bff85f48f3fff -C extra-filename=-a81bff85f48f3fff --out-dir /Users/bradjc/git/riscv-crates/target/riscv32ia-unknown-none/debug/examples --target riscv32ia-unknown-none -L dependency=/Users/bradjc/git/riscv-crates/target/riscv32ia-unknown-none/debug/deps -L dependency=/Users/bradjc/git/riscv-crates/target/debug/deps --extern stlog=/Users/bradjc/git/riscv-crates/target/riscv32ia-unknown-none/debug/deps/libstlog-b2aea226f0f7a980.rlib --extern nb=/Users/bradjc/git/riscv-crates/target/riscv32ia-unknown-none/debug/deps/libnb-f3f365033ce27152.rlib --extern spin=/Users/bradjc/git/riscv-crates/target/riscv32ia-unknown-none/debug/deps/libspin-7aef2ff5910100ed.rlib --extern numtoa=/Users/bradjc/git/riscv-crates/target/riscv32ia-unknown-none/debug/deps/libnumtoa-b2f04265b95f344f.rlib --extern riscv=/Users/bradjc/git/riscv-crates/target/riscv32ia-unknown-none/debug/deps/libriscv-83a89d7af68116e2.rlib --extern riscv_rt=/Users/bradjc/git/riscv-crates/target/riscv32ia-unknown-none/debug/deps/libriscv_rt-5146bd7d0d4567f1.rlib --extern hifive=/Users/bradjc/git/riscv-crates/target/riscv32ia-unknown-none/debug/deps/libhifive-adb02ffbf3438e5f.rlib --extern e310x=/Users/bradjc/git/riscv-crates/target/riscv32ia-unknown-none/debug/deps/libe310x-b4cdafbfad61b96d.rlib --extern e310x_hal=/Users/bradjc/git/riscv-crates/target/riscv32ia-unknown-none/debug/deps/libe310x_hal-772deef53db13f0c.rlib --extern riscv_semihosting=/Users/bradjc/git/riscv-crates/target/riscv32ia-unknown-none/debug/deps/libriscv_semihosting-08b349b8ede4c014.rlib --extern riscv_crates=/Users/bradjc/git/riscv-crates/target/riscv32ia-unknown-none/debug/deps/libriscv_crates-cecdf4f7dc368071.rlib -C link-arg=-Tmemory.x -C link-arg=-Tlink.x -C link-arg=-Tstlog.x -C linker=riscv32-unknown-elf-ld -C target-feature=+m -L /Users/bradjc/git/riscv-crates/target/riscv32ia-unknown-none/debug/build/riscv-rt-732869a40d34c185/out -L /Users/bradjc/git/riscv-crates/target/riscv32ia-unknown-none/debug/build/e310x-hal-51d2ac46bf89cbb1/out -L /Users/bradjc/git/riscv-crates/target/riscv32ia-unknown-none/debug/build/stlog-a77e423998c2d997/out

[bradjc]

I added a riscv32iam-unknown-none target (src/librustc_target/spec/riscv32iam_unknown_none.rs) to rust and compiled with that. That worked (at least it compiles and links successfully).

diff --git a/src/librustc_target/spec/mod.rs b/src/librustc_target/spec/mod.rs
index 9410628593..964e0012c9 100644
--- a/src/librustc_target/spec/mod.rs
+++ b/src/librustc_target/spec/mod.rs
@@ -376,6 +376,7 @@ supported_targets! {

     ("riscv32i-unknown-none", riscv32i_unknown_none),
     ("riscv32ia-unknown-none", riscv32ia_unknown_none),
+    ("riscv32iam-unknown-none", riscv32iam_unknown_none),
 }

 /// Everything `rustc` knows about how to compile for a specific target.

I'm not sure why the "-C", "target-feature=+m", isn't having the same effect.

[dvc94ch]

Probably because it's not applied to libcore, since it's built by dist and not xargo

[dvc94ch]

So what are the thoughts on targets to support?

• riscv32i-unknown-none and riscv32im-unknown-none are useful for educational purposes (building your own core)
• riscv32imc-unknown-none is useful for soft-cores (picorv32)
• riscv32imac-unknown-none is useful for the sifive e310x chips

I don't have a board available to test it works currently - since I'm not at home. After that I think we can submit a PR upstream.

Anyone interested in reviewing the c abi stuff?

[bradjc]

Based on that, riscv32imc-unknown-none and riscv32imac-unknown-none might be the two to start with.

[japaric]

@dvc94ch

Also I'm glad to add people to the riscv-rust org so that I'm not a bottleneck

We can mention that in the "Help wanted" section of the WG newsletter that goes out this week. Also, in the next meeting (rust-lang-nursery/embedded-wg#130) we'll discuss making orgs / teams to maintain the cortex-m / embedded crates on crates.io; we could mention that you are looking for collaborators during the meeting.

So what are the thoughts on targets to support?

I would suggest adding, for now, only the targets that have been tested on real hardware.

Anyone interested in reviewing the c abi stuff?

I can take a look but I'm not familiar with the RISCV ABI. A doc like this one but for RISCV would be great to have as a reference. In any case it may be a good idea to have someone on the compiler team take a look at the cabi stuff -- I believe the API has changed since last time I wrote one cabi module myself.

[dvc94ch]

@japaric thanks.

• rust patches: https://github.com/riscv-rust/rust/commits/riscv-rust-pr (I'll drop all except riscv32imac)
• __mulsi3 builtin: https://github.com/riscv-rust/compiler-builtins/commit/c200f6dd62fc538cb5abf0832a95976640120e0e
• psabi doc: https://github.com/riscv/riscv-elf-psabi-doc

[japaric]

@dvc94ch The changes mostly LGTM. I left some comments / questions in the commits. If no patches on top of the current Rust LLVM 7 fork are required I think this is ready for a PR.

[japaric]

RISCV support is now available in the latest nightly. You can compile crates for RISCV using the riscv32imac-unknown-none-elf target and Cargo:

$ cargo new --lib foo
$ cd foo
$ cat src/lib.rs

#![no_std]

#[no_mangle]
pub fn foo(x: u32, y: u32) -> u32 {
    x + y
}

$ rustup target add riscv32imac-unknown-none-elf
$ cargo build --target riscv32imac-unknown-none-elf --release
$ cargo install cargo-binutils
$ cargo objdump -- -arch-name=riscv32 -d -no-show-raw-insn target/riscv32imac-unknown-none-elf/release/libfoo.rlib
target/riscv32imac-unknown-none-elf/release/libfoo.rlib(foo-5f01dd28752961b9.foo0-d59093d565f158ef2f92ae2d0a10a47.rs.rcgu.o):     file format ELF32-riscv

Disassembly of section .text.foo:
foo:
       0:       add     a0, a1, a0
       4:       ret

---

@dvc94ch

now that RISCV support has landed do you want to keep this issue open, or close it in favor of more targeted issues in this repo and/or in the riscv-rust repos?

Also, do you think it would be possible to reduce the number of unstable features in riscv-rt? cortex-m-rt is using zero unstable features at the moment. How this was achieved is covered in the embedonomicon.

---

Removing this issue from the RC1 milestone as embedded supported in now in tree.

[dvc94ch]

Yes it's on the todo list. We have 12 weeks till it's in stable, so that's the target time frame...

[japaric]

@dvc94ch Thanks. Could you create issues for the stuff you want to get done by the edition release in the riscv-rust and assign them tentative milestones (RC1, RC2; see this repo milestones)? And then link them here?

It's true that RISCV has 12 weeks until it hits stable but #![no_std] binaries should be possible in beta in 6 weeks. We'll like to get everyone to move from nightly to beta by then to avoid them depending on unstable features that won't be stabilized.

[dlan17]

hi guys, has anyone tried to bootstrap rust natively on Linux (not the embedded)?

I'm recently trying to do that, but fail at compiler_builtins .. https://github.com/rust-lang/rust/issues/83970