RISCV Arch Support #36
Comments
|
I just wanted to add - that's amazing!! |
|
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 PCThis 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 |
|
@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 |
|
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'm having some trouble implementing this feature correctly. When should My work in progress patch emits a .debug_frame section when all Rust when compiling with panic=abort declares @nounwind on all rust rustc doesn't like that very much and when doing -emit=obj of an |
@dvc94ch Sorry, this is beyond my knowledge. Maybe @michaelwoerister or @tromey can give you some pointers; they are most familiar with Rust debuginfo internals. |
|
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...
|
|
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. |
|
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. |
|
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
|
|
@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. |
|
Need to try it to know for sure, but it seems that there isn't much missing. That sounds like a plan... |
|
@japaric Do you think that rust would accept a llvm fork like llvm-emscripten for riscv until llvm7 is released? |
|
@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). |
|
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...
|
|
@dvc94ch Yeah, I think we should not have the users build LLVM from source; that's too high a entry barrier. |
|
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. |
|
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 |
|
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 < ***@***.***> 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
<#36 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AAtRr13hKETTRWD8TbgTy-UhDRwW0GDhks5t3_B8gaJpZM4O9aY_>
.
|
|
With rust-lang/rust#51966 being merged (update to use LLVM 7 for nightly rust), where does this stand? |
|
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... |
|
@bradjc all I can say is that it builds core until japaric/xargo#218 is resolved... |
|
@dvc94ch can you share a pointer to what you are building? |
|
rust: https://github.com/riscv-rust/rust/commits/riscv-rust-nightly |
|
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. |
|
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 Over in riscv-crates I ran: 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: and added Finally, in rustv-crates: That's how far I have gotten. It seems like adding riscv as a target to nightly rust is quite possible right now. |
|
Just FYI 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 |
|
That flag is already there: and I verified that it is included in the rustc command. |
|
I added a 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 |
|
Probably because it's not applied to libcore, since it's built by dist and not xargo |
|
So what are the thoughts on targets to support?
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? |
|
Based on that, |
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.
I would suggest adding, for now, only the targets that have been tested on real hardware.
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. |
|
@japaric thanks.
|
|
@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. |
|
RISCV support is now available in the latest nightly. You can compile crates for RISCV using the $ 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: retnow 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. |
|
Yes it's on the todo list. We have 12 weeks till it's in stable, so that's the target time frame... |
|
@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. |
|
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 .. |
Tracking issue for riscv support:
riscv-rust-toolchain
llvm and rustc
these are likely not going to get done for Epoch 2018 release:
llvm upstreaming (wip, asb is working on this)
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:
The text was updated successfully, but these errors were encountered: