wg
wg copied to clipboard
rust-embedded
Completely prebuilt riscv rust toolchain
LLD support for RISCV just landed upstream! https://github.com/llvm-mirror/lld/commit/9e54d159934e86f7a83c58ed21341bc89ff2bd2b https://github.com/riscv/riscv-lld/issues/1
- [x] Wait for rust's llvm/lld to be updated
- [x] Test lld for the riscv target
- [x] Enable it in the target spec by default
- [ ] Ship gdb --enable-targets=all with rustup https://github.com/rust-embedded/wg/issues/43
FYI I have been testing lld already (from the rust-lld fork) and we have a bunch of fixes we need to do in riscv-rt... I will post patches soon, was struggling to get past that stuff with #[naked] first :-)
It looks like the lld patch landed in master. Do we know if they will backport it to the 7.x branch?
If they do, do we know if/when rust will rebase its lld 7.x tree?
@danc86 I don't think anyone is going to backport the patch for us. We can submit a PR against rust-lld since a backport might be accepted.
Instead of backporting the patches you could update the lld fork to the latest upstream version (if it doesn't require updating the llvm fork).
Yeah it might be a bit tricky. I noticed that the upstream release_70 branch of lld has accumulated a bunch of commits that depend on new enum values and header changes in the release_70 branch of llvm. So they would have to updated in sync with each other I think.
I am not familiar enough with how llvm and lld do their branches and releases though...
thanks to @danc86 for his work on lld support! https://github.com/rust-lang/lld/pull/1
Ah, posting rust-lang/lld#1 was easy :-) all the hard work went into rust-embedded/riscv-rt#10 instead :sweat_smile:
Alex just merged the lld patch as well, so we should be able to update the riscv32imac-unknown-none-elf target to use rust-lld next!
PR to update lld in rust-lang/rust was: https://github.com/rust-lang/rust/pull/53492
It was merged several days ago but there seems to be no new build ready to be rustup'ed just yet.
Once rustup can give you a nightly with working lld I will post another PR to update the riscv32imac-unknown-none-elf target to use it by default.
@danc86 have you tried the c extension recently? This https://github.com/rust-embedded/riscv-rt/pull/8#event-1781782531 likely fixed the issues I was having. I haven't tried it since I'm currently to lazy to build rustc from src :smile:
You should be able to test +c by just tweaking compiler flags in .cargo/config, right? Or with a custom target spec. I don't think you need to rebuild all of rust.
I haven't tried it myself, will give it a go over the weekend.
I thought we needed the .push(norelax) thingy when setting the global pointer, don't we? Or does that not matter since rust-lld can't actually do the relaxations right now anyway? :-)
I also want to go back to gdb and figure out why its stack traces are broken... I've got a laundry list of stuff to investigate when I have some free time over the weekend. :-)
You should be able to test +c by just tweaking compiler flags in .cargo/config, right? Or with a custom target spec. I don't think you need to rebuild all of rust.
Libcore won't be built with the +c flag then. But I guess it's not required for testing purposes...
I thought we needed the .push(norelax) thingy when setting the global pointer, don't we? Or does that not matter since rust-lld can't actually do the relaxations right now anyway? :-)
yes that is what I was thinking...
Oh right. I have been using cargo xbuild to rebuild core whenever I fiddle with the target. It seems to work.
@danc86 @dvc94ch how did the LLD experiments go? People were asking about this (switching the RISCV targets to LLD) on reddit.
Just started testing it today, can't say yet. Building a small example soc that provides embedded hal drivers in a plug and play fashion. So you select the components and get a hal that is for the soc.
Meanwhile there are a variety of different toolchains available out-of-the-box: https://doc.rust-lang.org/nightly/rustc/platform-support.html
So I think this issue can be considered done.
