tracking: Towards full LLVM (no gnu toolchain) builds

[kaspar030]

Description

Currently, RIOT has limited LLVM support - it allows compiling with LLVM. Linking is still using the gnu toolchain. Also, our libcs (newlib, picolibc) are gcc compiles, and thus depend on libgcc.

Those dependencies have several drawbacks:

1. LLVM+LTO doesn't work (as GNU ld doesn't understand clang's bitcode)
2. LLVM+LTO can't do LTO between libc/libgcc and RIOT code
3. There's a GCC toolchain per architecture, those are maintenance heavy and fragmented. Pure LLVM would reduce this to a single toolchain for most architectures (well, maybe xtensa would still need another build...). With pure-LLVM support, we could have a (possibly alternative) much thinner riotdocker image.
4. Rust code (incl. RIOT-rs) is built using LLVM, the gcc linker prevents cross-language LTO

This is issue will track work necessary for LLVM-only builds.

• [ ] make linker scripts compatible with lld
  • [ ] https://github.com/RIOT-OS/RIOT/pull/19692
• [ ] provide llvm-built libcs
  • [ ] picolibc allows building using llvm -> provide builds
  • [ ] while LLVM / clang usually support compiling for all architectures, they generate code that requires compiler-rt. -> provide builds of that
  • [ ] gcc has a working multilib mechanism to select the correct libc for a (sub-)architecture when linking. llvm doesn't, so this needs to be worked around
  • [ ] lld doesn't support spec files. directly select the correct libs

[maribu]

lld doesn't support spec files. directly select the correct libs

ld also doesn't support a -specs argument, only GCC. I haven't actually looked into it, but I would assume that GCC would use the specs file to read how to correctly invoke the linker. Since clang has -specs support I would expect to do the same, so lld wouldn't need support for specs.

If the long term goal is to completely get rid of GNU toolchains, IMO we should also not forget that right now a number of modules & packages won't build at all with LLVM. As a step into the direction we could first aim for re-enabling LLVM builds in the CI and eventually all boards & apps build with LLVM, and only a subset with GCC as well.

In addition, some platforms are not supported by LLVM yet.

I think that clang 16 is now indeed able to build RIOT against a patched version avrlibc that still needs to be build with avr-gcc. But in order to build avrlibc, https://github.com/llvm/llvm-project/issues/55159 would need to be addressed first. Or avrlibc would need to be changed to never use 32 bit register allocations (which would result in less readable code, though).

For ESP there is downstream LLVM support. I bet that we will end up replacing magic GCC binaries from Espressif with magic clang binaries from Espressif for those MCUs :cry:

[kaspar030]

ld also doesn't support a -specs argument, only GCC. I haven't actually looked into it, but I would assume that GCC would use the specs file to read how to correctly invoke the linker. Since clang has -specs support I would expect to do the same, so lld wouldn't need support for specs.

hm, but the "specs" only do things like "replace -lc with -lc_nano". In the RIOT case, just doing "-lc_nano" instead of "-lc --specs=nano.specs" would save bytes in the Makefiles and work for all linkers. Also, does clang work with specs and lld? By default on our little arms, clang defaults to linking with gnu ld ...

(Why do we support non-newlib-nano builds in the first place?)

[kfessel]

Lazy FPU Save/Restore (CVE-2018-3665) - Red Hat Customer Portal might be conected to that llvm not saving fpu bug

maybe some fences in out tramp.S might help https://linux.kernel.narkive.com/aE2eABtt/rfc-patch-x86-fpu-use-eagerfpu-by-default-on-all-cpus#post32

might be connected to some kernel version/flags and cpu generation

[kfessel]

lets connect #18851

[nmeum]

lld doesn't support spec files. directly select the correct libs

Related: https://github.com/picolibc/picolibc/issues/803

[keith-packard]

oh, picolibc is also happy to use llvm's ABI support library that replaces libgcc. I've got several CI tests which don't use any gcc bits.

[abrodkin]

oh, picolibc is also happy to use llvm's ABI support library that replaces libgcc. I've got several CI tests which don't use any gcc bits.

Do you mean LLVM's "compiler-rt" library (https://github.com/llvm/llvm-project/tree/main/compiler-rt)?

[keith-packard]

Do you mean LLVM's "compiler-rt" library (https://github.com/llvm/llvm-project/tree/main/compiler-rt)?

Yeah, that's the one -- I'd forgotten the name.