roadmap to stable rust

[rursprung]

it'd be great if you could add a roadmap which identifies what still needs to be done in order to build & use this with a stable rust toolchain (instead of nightly). thanks!

[Rahix]

I don't think we will see AVR on stable rust anytime soon, there is so much that still needs to be worked on... In any case, here are the big topics that come to my mind:

• The LLVM backend for AVR is still not entirely stable. I don't have good overview at this time where the limitations are - maybe @Patryk27 can comment on that. He's responsible for a large number of codegen fixes without which AVR would still be mostly unusable. Ideally, we also want a stable lld for AVR so we can drop all dependencies on avr-gcc and avr-binutils.
• We depend on the use of json-target specs which are not really well supported throughout the rust toolchain and surrounding ecosystem - many things still break when using them.
• We need the beast that is https://github.com/rust-lang/wg-cargo-std-aware without which we cannot build libcore for the different AVR architecture flavors.

[Patryk27]

The LLVM backend for AVR is still not entirely stable.

I think nowadays it's pretty good, there's not that many opened bugs and I'm not aware of any show-stoppers (although rust-lang/rust#109000 remains suspicious).

@benshi001 is doing great job maintaining the backend - most of the issues in the recent months were caused by linking wrong intrinsics (on rustc's side), not by codegen itself being wrong.

Ideally, we also want a stable lld for AVR so we can drop all dependencies on avr-gcc and avr-binutils.

This shouldn't be extremely difficult - IIRC we use avr-gcc mostly because it brings certain hand-written intrinsics (e.g. for i32 multiplication) - in principle those could be sourced from compiler-builtins instead, but the issue is that AVR requires a custom calling convention that hasn't been yet implemented in LLVM (and thus exposed in rustc).

Moving from hand-written intrinsics to auto-generated ones would also warrant a benchmark, since e.g. making i32 multiplication ten times slower wouldn't be that great 👀

(or maybe rustc/lld could just automatically link those hand-written intrinsics, to reuse the work already done? I'm not sure on potential license issues here, though.)

[benshi001]

I am not familiar with rust, and I am now taking the responsibility of maintaining the llvm-avr backend (though it is my spare time work).

I am glad if you can help me test the toolchain llvm+CompilerRT+lld, and report bugs to me at here

Here are some known issues if you want to get rid of GNU toolchain:

1. The lld does not support some odd linker script syntax of avr-ld, such as KEEP(SORT(*)(.dtors)) as examples in binutils. It would be better to specify a modified version (instead of the avr-ld's default one) to lld via option -T xxx.lds.

2. I think all AVR relocations have been supported by lld, however more tests are needed, here are my tests (of course very rough): avr-flags.s / avr-reloc-error.s / avr-reloc.s / avr-thunk-ldi-gs.s / basic-avr.s

3. Some runtime functions are still missing in compiler-rt, especially 32-bit multiplication/division. (But as far as I know, rust-avr has its own implementation and does not depend on compiler-rt / libgcc?)

4. For the custom calling convention, I do not give it a high priority, so these functions are still in the standard calling conventions, this way only makes harm if you link avr-gcc compiled OBJ files and llvm compiled ones. But current llvm's way even works if you link llvm compiled OBJ files with libgcc.

[benshi001]

Update: The custom calling convention does not break the standard version, which is llvm's current implementation. So current AVR assembly generated by llvm should work, though a little less efficient.

And of course, I am happy if you can offer rust's implementation of int32 mul/div to compiler-rt, as shown at here.

[benshi001]

I think the llvm-avr backend should be more stable than lld, and I really appreciate if you can try lld and feedback me issues !