Maintainers for embedded targets

[adamgreig]

Currently many of the targets used for embedded development on Rust do not have official maintainers, because they were added before the current maintainer policy was adopted. There is currently work upstream to ensure all targets have maintainers, and it is likely that tier 2 targets that cannot find maintainers are eventually demoted.

rust-lang/rust#116004

After discussion in the weekly meetings, I'm proposing we nominate the @rust-embedded/cortex-m team to maintain the thumb*-none-eabi* targets. If the @rust-embedded/riscv team is interested we could also nominate them for the risc-v targets.

The main obligation that comes with being a target maintainer is being available to respond to occasional queries about the target or requests to test changes that the compiler team cannot; in general the idea is that the maintainers have an active interest in using the target and seeing it kept within Rust.

To be specific I'm suggesting we become the maintainer for: thumbv6m-none-eabi, thumbv7em-none-eabi, thumbv7em-none-eabihf, thumbv7m-none-eabi, thumbv8m.base-none-eabi, thumbv8m.main-none-eabi, and thumbv8m.main-none-eabihf.

I'm happy to put together the relevant PR if we approve:

• @adamgreig
• @thejpster
• @therealprof
• @newAM
• @thalesfragoso

I haven't spoken to the @rust-embedded/riscv team yet but if they're interested in the riscv32i-unknown-none-elf, riscv32imac-unknown-none-elf, riscv32imc-unknown-none-elf, riscv64gc-unknown-none-elf, riscv64imac-unknown-none-elf, or riscv32im-unknown-none-elf targets I'm happy to add them to the same PR (or they can make their own). Similarly if there are any other targets people in the WG think we could support.

[almindor]

I haven't spoken to the @rust-embedded/riscv team yet but if they're interested in the riscv32i-unknown-none-elf, riscv32imac-unknown-none-elf, riscv32imc-unknown-none-elf, riscv64gc-unknown-none-elf, riscv64imac-unknown-none-elf, or riscv32im-unknown-none-elf targets I'm happy to add them to the same PR (or they can make their own). Similarly if there are any other targets people in the WG think we could support.

I'm happy to help with riscv32imac as that's what I have, I cannot do practical things with the others I'm afraid.

[cr1901]

Apparently Tier 3 targets need a maintainer too. I'm fine w/ either the msp430 team or myself being a maintainer (cc: @YuhanLiin, would you be open to maintaining it too?). I already kinda maintain it, anyway.

[newAM]

I'm onboard to help maintain these targets! I don't know as much as I would like to about the thumv8m ISA though 😅

[thejpster]

So this is a good backstop, but honestly I'd much rather Arm was listed as the maintainer, as they are for aarch64-unknown-linux-gnu. I understand that they will already help fix issues if we tag the right people, but there's some discussion about whether they're happy to have their name actually listed.

[thejpster]

Equally it would be nice if the RISC-V targets were maintained by the RISC-V Foundation, or if they sponsored someone to maintain them.

[therealprof]

So this is a good backstop, but honestly I'd much rather Arm was listed as the maintainer, as they are for aarch64-unknown-linux-gnu. I understand that they will already help fix issues if we tag the right people, but there's some discussion about whether they're happy to have their name actually listed.

I agree that having the official makers of the stuff onboard to be co-maintainers would be better. In any case we additionally should have rewg people on board rather than outsourcing this completely without any possibility of collaboration...

[thejpster]

That's a fair point. We should be co-maintainers.

[thejpster]

Let's get the cortex-m team added now, and I'll continue to talk to Arm about this. They could be co-maintainers, or they could just have someone join the cortex-m team. Either would work.

[romancardenas]

I haven't spoken to the @rust-embedded/riscv team yet but if they're interested in the riscv32i-unknown-none-elf, riscv32imac-unknown-none-elf, riscv32imc-unknown-none-elf, riscv64gc-unknown-none-elf, riscv64imac-unknown-none-elf, or riscv32im-unknown-none-elf targets I'm happy to add them to the same PR (or they can make their own). Similarly if there are any other targets people in the WG think we could support.

I'm happy to help with riscv32imac as that's what I have, I cannot do practical things with the others I'm afraid.

Same here, I can help with RISC-V 32 targets. I currently do not have any RISC-V 64 board, but I plan to eventually work with those targets as well.

[adamgreig]

Thanks for the responses everyone. I've started to put together a branch with the relevant details.

Please could you check the relevant files, let me know if anything is missing or wrong, if there's any more details you think should be present, or any other links or docs:

• MSP430
• RV32
  • I've combined i, imc, and imac into one file, as they're all tier 2 targets with no existing details
  • I've left im alone because it's somehow tier 3 and does have a nominal maintainer, though it might make more sense to see if we can have it promoted to tier 2 and then its platform file merged with this one
  • The "building rust programs" and "cross-compilation toolchains and C code" sections are missing, any ideas here? The template has a little guidance of what to put in each section.
• thumbv6
• thumbv7
• thumbv8
  • I merged baseline and mainline as I expect the details will be the same for them and we've merged all the v7 targets together too.

Feel free to leave comments here or open a PR against my branch, once we're happy with it I'll submit it as a PR to rust-lang/rust#116004

[cr1901]

This target supports interlinking with C code compiled using the TI MSP430 GCC compiler.

Yes this is correct, but I would put a caveat that cross-language LTO w/ the GCC compiler almost certainly doesn't work (b/c LLVM vs GCC's IR). I would also put a note that nightly is required for the forseeable future until at least rust-lang/rfcs#3246 and by extension rust-lang/rust#38487 are resolved. Because we're stuck on nightly, I have not felt an impetus to get rid of the build-std=core invocation (and honestly, I kinda hope at some point build-std is just stabilized and we don't need to provide libcore).

[jonathanpallant]

thumbv8m.main-none-eabi points to thumbv8m.main-none-eabihf

but

thumbv7em-none-eabihf points to thumbv7m-none-eabi

We should probably have the 'lowest' target as the one that gets the file and then have the others point at it? Doesn't make a big difference though.

[jonathanpallant]

The -eabihf target enables the hardware FPU and uses the hard-float ABI.

I would add:

If you want to use the FPU with the soft-float ABI, you can use the -eabi' target, but add extra RUSTFLAGSlike-mcpu=+vfp` (I made that up).

[jonathanpallant]

The thumbv8m file says:

This target supports C code. Use the thumbv6m-none-eabi triple in LLVM. If interlinking with C or C++, you may need to use arm-none-eabi-gcc as a linker instead of the built-in LLD.

That's probably the wrong LLVM target? Also s/the built-in LLD/the default rust-lld linker/.

[jonathanpallant]

Maybe in the thumbv6m-none-eabi target file we could point them at atomic-polyfill?

Also I think my notes above apply to the thumbv7m target file too; but I really liked the Floating Point section so maybe copy that to the thumbv8 file?