Comments (40)
I just wanted to add - that's amazing!!
from wg.
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
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.
Need to try it to know for sure, but it seems that there isn't much missing. That sounds like a plan...
from wg.
@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.
@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.
@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.
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.
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.
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.
from wg.
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.
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.
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.
from wg.
@japaric Do you think that rust would accept a llvm fork like llvm-emscripten for riscv until llvm7 is released?
from wg.
@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.
from wg.
@dvc94ch Yeah, I think we should not have the users build LLVM from source; that's too high a entry barrier.
from wg.
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.
That uses the gcc toolchain. That's not too relevant to rust on riscv
from wg.
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.
from wg.
With rust-lang/rust#51966 being merged (update to use LLVM 7 for nightly rust), where does this stand?
from wg.
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.
@bradjc all I can say is that it builds core until japaric/xargo#218 is resolved...
@japaric any ideas?
from wg.
@dvc94ch can you share a pointer to what you are building?
from wg.
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.
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.
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.
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.
That flag is already there:
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.
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.
Probably because it's not applied to libcore, since it's built by dist and not xargo
from wg.
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.
Based on that, riscv32imc-unknown-none
and riscv32imac-unknown-none
might be the two to start with.
from wg.
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.
@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
from wg.
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.
@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.
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)
- Agenda for 2020-09-08 Meeting
- Agenda for 2020-09-15
- Propose to transfer RustSBI project to rust-embedded community HOT 1
- AVR flashing tool. Help needed HOT 2
- Mailing list? HOT 6
- Making `panic-never` a requirement or convention for `rust-embedded` libraries where feasible HOT 19
- Calliope Mini HOT 2
- Track upstream double-panic issue
- Support `riscv32imf-unknown-none-elf (Baremetal)` in rust as a cross compile target? HOT 1
- Tracking Issue: Rust Embedded on Mastodon HOT 9
- Display showcase on rust-embedded.org landing page HOT 1
- Benchmarking embedded rust code HOT 3
- How can I contribute to the embedded wg? HOT 1
- bors-ng is being retired HOT 11
- [Question] Experience with cadence chips HOT 2
- Propose transferring svdtools to tools team HOT 1
- Maintenance of meta-rust-bin HOT 2
- Maintainers for embedded targets HOT 30
- Transfer heapless and volatile-register to libs team HOT 13
- Tracking Issue: Call for blog posts, EoY 2023 HOT 12
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
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.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from wg.