Giter VIP home page Giter VIP logo

Comments (40)

thejpster avatar thejpster commented on July 30, 2024 4

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

from wg.

japaric avatar japaric commented on July 30, 2024 3

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.

from wg.

dvc94ch avatar dvc94ch commented on July 30, 2024 2

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

from wg.

japaric avatar japaric commented on July 30, 2024 1

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

from wg.

japaric avatar japaric commented on July 30, 2024 1

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

from wg.

japaric avatar japaric commented on July 30, 2024 1

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

from wg.

dvc94ch avatar dvc94ch commented on July 30, 2024

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

from wg.

dvc94ch avatar dvc94ch commented on July 30, 2024

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.

from wg.

japaric avatar japaric commented on July 30, 2024

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.

from wg.

dvc94ch avatar dvc94ch commented on July 30, 2024

from wg.

dvc94ch avatar dvc94ch commented on July 30, 2024

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.

from wg.

dvc94ch avatar dvc94ch commented on July 30, 2024

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.

from wg.

japaric avatar japaric commented on July 30, 2024

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

from wg.

dvc94ch avatar dvc94ch commented on July 30, 2024

from wg.

dvc94ch avatar dvc94ch commented on July 30, 2024

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

from wg.

japaric avatar japaric commented on July 30, 2024

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

from wg.

dvc94ch avatar dvc94ch commented on July 30, 2024

from wg.

japaric avatar japaric commented on July 30, 2024

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

from wg.

glaubitz avatar glaubitz commented on July 30, 2024

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.

from wg.

dvc94ch avatar dvc94ch commented on July 30, 2024

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

from wg.

glaubitz avatar glaubitz commented on July 30, 2024

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

from wg.

dvc94ch avatar dvc94ch commented on July 30, 2024

from wg.

bradjc avatar bradjc commented on July 30, 2024

With rust-lang/rust#51966 being merged (update to use LLVM 7 for nightly rust), where does this stand?

from wg.

dvc94ch avatar dvc94ch commented on July 30, 2024

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

from wg.

dvc94ch avatar dvc94ch commented on July 30, 2024

@bradjc all I can say is that it builds core until japaric/xargo#218 is resolved...
@japaric any ideas?

from wg.

bradjc avatar bradjc commented on July 30, 2024

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

from wg.

dvc94ch avatar dvc94ch commented on July 30, 2024

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)

from wg.

dvc94ch avatar dvc94ch commented on July 30, 2024

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.

from wg.

bradjc avatar bradjc commented on July 30, 2024

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.

from wg.

danc86 avatar danc86 commented on July 30, 2024

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.

from wg.

bradjc avatar bradjc commented on July 30, 2024

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

from wg.

bradjc avatar bradjc commented on July 30, 2024

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.

from wg.

dvc94ch avatar dvc94ch commented on July 30, 2024

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

from wg.

dvc94ch avatar dvc94ch commented on July 30, 2024

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?

from wg.

bradjc avatar bradjc commented on July 30, 2024

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

from wg.

japaric avatar japaric commented on July 30, 2024

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

from wg.

dvc94ch avatar dvc94ch commented on July 30, 2024

@japaric thanks.

from wg.

dvc94ch avatar dvc94ch commented on July 30, 2024

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

from wg.

japaric avatar japaric commented on July 30, 2024

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

from wg.

dlan17 avatar dlan17 commented on July 30, 2024

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 ..
rust-lang/rust#83970

from wg.

Related Issues (20)

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.