Repository navigation
AVR support #3
Description
Parent issue: #2
Next steps:
- Wait until AVR support lands in upstream LLVM
- Update rust-lang LLVM fork (Upgrade to LLVM 4.0 rust-lang/rust#37609), implement cabi stuff, etc.
- Experiment with custom targets out of tree (to get the specification right)
- Get libcore compiling without modifications
- Upstream all LLVM patches required for the AVR fork (Upstream all of the patches for llvm-8.0svn support avr-rust/rust-legacy-fork#116)
- Write documentation about writing/compiling/flashing/debugging Rust
programs for this target - Add the AVR target to the compiler (as a built-in target) (tracking issue RFC: Merging the avr-rust fork upstream rust-lang/rust#44052)
- 🎉
See also avr-rust/rust for out of tree work towards AVR support in Rust.
Activity
dylanmckay commentedon Oct 12, 2016
Here's an email I sent out to the
llvm-devlist very recently regarding the status of the AVR backend.tl;dr there's really only 3 files needed before the backend will be 80% usable.
japaric commentedon Nov 1, 2016
Hey, @dylanmckay. I'm wondering what's the current status. I saw that there's only one "PR" (differential revision) in the review queue and that it has already been accepted but has not landed yet.
After that lands, will LLVM be ready to compile Rust programs for AVR? Will you (and @shepmaster) be sending a PR updating Rust's LLVM next?
Happy to help with anything to land this in rust-lang/rust. 😄 (I should finish landing my PR that moves rust-lang/rust to the WIP Rust port of compiler-rt intrinsics; I suspect that it may help here)
shepmaster commentedon Nov 1, 2016
Eventually, yeah, except the LLVM 4.0 changes are more annoying than any previous LLVM changes I've had to make.
I think it will help. Especially because one "bug" we have at the moment is that I've forgotten to publish the WIP branch of compiler-rt so people are getting build failures.
japaric commentedon Nov 1, 2016
I'm really looking forward to LLVM 4.0 in rust-lang/rust so if you make it happen you'll have my gratitude.
Did you have to implement new intrinsics? I only see build system related changes in your fork.
shepmaster commentedon Nov 1, 2016
What benefits do you expect to see from it?
I think we might have to, but haven't yet.
japaric commentedon Nov 1, 2016
I'm working on embedding lld, the LLVM linker, into
rustcand having LLVM 4.0 lets me use the latest lld release which has better linker script support. (Linker script support in lld 3.9 is minimal) I'm hoping that someday I'll be able to build Rust programs for Cortex M devices without having to installarm-none-eabi-gccfirst.dylanmckay commentedon Nov 2, 2016
I'm about to commit that one now :)
It should be able to compile very trivial instructions. There are two source files that will fix that.
AVRBranchSelector- The branch relaxation pass (which will be rewritten to use the generic relaxation pass before it is merged)AVRExpandPseudoInsts- This is required for basically any 16-bit operation (hint: almost everything). I've put this one off until last because we can compile really basic examples without it. On top of that is that it is essentially a 2000 line hack full of code duplication.raphaelcohn commentedon Nov 5, 2016
@japaric Big shout out for
lldembedded intorustc. It's not an easy thing to do - I know I'd struggle - but a rust toolchain that's entirely independent of GNU binutils and gcc is an enormous win for rust.japaric commentedon Nov 5, 2016
@raphaelcohn Check rust-lang/rust#36120. It's pretty much already working on Linux and it can link Cortex-M programs without arm-none-eabi-gcc. It hasn't landed because I couldn't get lld to build properly on Windows 😞
Indeed! If all goes well we'll also be able to (cross) compile statically linked MUSL binaries without needing glibc installed on the system as well. Ahh, the dream of the "zero installation steps" cross compilation setup may soon come true.
dylanmckay commentedon Nov 8, 2016
12 remaining items
dylanmckay commentedon Feb 27, 2018
@japaric good catch, that's my mistake.
I wonder if it worked for me because it always evaluated to true. Easy to replace with
#[cfg(target_arch)]though.japaric commentedon Aug 2, 2018
@dylanmckay rustc moved to LLVM 7 a few weeks ago. I believe the last upgrade to LLVM 6 ended up increasing the number of codegen bugs encountered when building core. Was wondering if you had a chance to check if moving to LLVM 7 improved things or made them worse?
brainlag commentedon Aug 7, 2018
There are at least 2 bugs left: avr-rust/rust-legacy-fork#101 and avr-rust/rust-legacy-fork#103
shepmaster commentedon Nov 14, 2018
FWIW, we moved to LLVM 8 recently, thanks to @TimNN. We've been able to compile the entire core library (probably not using all of it though), removing the need for our special hacked libcore.
ZhangHanDong commentedon Dec 17, 2018
One of the Rust 2019 Wish lists
dylanmckay commentedon Dec 19, 2018
I've updated the checklist for merge in the description and raised #282 to track performing a Crater run against AVR.
jplatte commentedon Dec 19, 2018
@dylanmckay I think you meant #282 ;)
dylanmckay commentedon Dec 19, 2018
Whoops, is it still a ninja edit 25 minutes later? 🤔
eldruin commentedon Aug 11, 2020
AVR support was merged into Rustc. Can this be closed now?
therealprof commentedon Aug 11, 2020
Yes, let's close this.