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:

• 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:

• svd2rust upstreaming (not much to do here, the missing svd features are supported in recent svd2rust, Add support for building the e310x crate svd2rust#185)
• split hifive crate into e310-hal and hifive crates, update to latest embedded-hal
• cross docker image for quick setup (related to One step setup #43 Cross with managed volumes cross-rs/cross#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?