LLVM Embedded Toolchains Working Group sync up

Community
94

2026-05-21

Agenda

  1. Code and RFC reviews

  2. Community

Discussion

Libraries folder layout

  • Peter: The difference seems to be in use cases: hosted vs baremetal.

  • Sam: Agreed, all resource directory files are coupled with the compiler - there is no separation between multlilibs. compiler_rt needs to be built per variant. Thus we need multiple versions of resource directory, this is why the current approach. Resource directories are added to both include and lib directories on the command line. May we should not add resource lib directories? Linux is not fundamental as a supported platform for the Qualcomm CPULLVM toolchain - mostly embedded.

  • Peter: We are thinking about adding cross compiling for AAArch64 Linux from ATfE, e.g. for benchmarking - some basic use cases.

  • Petr: Fuchsia/Google toolchain is different from the 2 above: the same for bare-metal, Fuchsia, Linux, macOS, Windows, … - number of platforms is only growing. Works to cross compile from any platform to any other platform. The difference is more about ABI, than host OS. On host OSes there are more ABI restrictions, while on bare-metal anything can be configured. In Fuchsia it is easy to change ABI - closer to bare-metal, than Linux (with the kernel ABI at the end).

    • 2 different approaches mean additional complexity.

    • There is a difference between compiler-rt libs (no fixed ABI, they depend on the compiler) vs libc/libc++ that are more stable on a host OS (but not necessary bare-metal).

    • How to come up with a single layout that can support all these use cases?

  • Peter: From the ABI/non-ABI angle, may be we should put all embedded libs into the resource dir then? To follow the logic of libraries tightly coupled with the compiler.

  • Sam: Fuchsia toolchain feels like 1st party vs Arm/QComm not - users are not recompiling libc, only use the pre-built variants. Happy to have difference between toolchains for users who rebuild the world vs not. ABI is fixed in the toolchain distribution.

  • Petr: Maybe it depends who defines/controls the ABI: toolchain vs platform.

  • Peter: Should we try to apply the LLVM libc design docs/workgroups example - start a working/design group to iterate faster with a smaller group of people?

  • Petr: It is unclear what are the problems with the current layout that need to be changed?

    • Options what we can do:

      • Keep the overall design as is and incrementally fix small issues.

      • Redraw the world.

    • Potential questions now:

      • Put multilib variants into the resource dir (for all drivers).

      • Support for different/multiple libc’s

        • Try to handle through multilib variants? Use --cstdlib as an extra parameter in multilibs selection. This issue seems to be ATfE specific (the only toolchain that uses multiple libraries at the same time).

      • Sam: One more question: multilibs are treated as sysroots that includes both “include” and “lib” while ATfE has a way to share “include” dirs between variants. There is an opportunity to use different logic for “include” and “lib”. Qualcomm CPULLVM toolchain does not need sysroot support, so it is OK to move closer to Linux layout: Linux triple dirs come after include or lib dirs on the command line (in bare-metal other way around, thus - different priorities of the dirs) to allow sharing of includes to save space.

  • => Agreed that Arm team will prototype support of multiple libraries with the multilibs selection mechanism.

Defaults in clang.cfg

  • Sam: Existing PR about clang.cfg - please comment. Hope to cut down on Fuchsia builder failures because of the defaults different from other buildbots.

  • Open questions whether to include into the cfg file: object copy? Default Linker?

Modular printf

  • Thanks to the libc team - enabled in ATfE now: resulted in 37K vs 13K code size for float vs int printf sample app.

LLVM libc workgroups update

  • Petr: Not met formally in a few months, not a lot of progress.

  • IO: there was a design, struggling to match/consolidate Linux and bare-metal requirements. For now, agreed to continue with the current design, but keep improving it incrementally: there will be no “file v2”. There are some ideas to try out.

  • Threading: Linux support is progressing. Building libc++ with libc on Linux and closing the gaps. Next: build all LLVM and clang with libc. Major gaps:

    • Wide chars support - missing implementation done.

    • Threading is more complicated because of the mismatch of API: libc++ and libc. libc++ provides std::thread and std::therad::id. The thread ID is a number with some reqs like comparable, copyable, …, but neither C11 standard nor pthreads provide such a thing - libc++ internally has different platform specific implementations: hardcoded #ifdefs how to handle this in each specific case. This will be different even for each libc, not only platform. In discussion with libc++ maintainers.

TLS support

  • Peter: There was this LLD PR that triggered this point: [lld][ELF] Allow explicit address expressions on .tbss output sections by amosher-nvidia · Pull Request #196447 · llvm/llvm-project · GitHub

  • picolibc has TLS and keeps it in the middle of all data so in the single threaded mode TLS comes as global data and “just works”. Otherwise needs to be copied for threaded use.

  • ELF format allows only one TLS definition. Someone requested more than one, it did not work.

  • Why is this needed? The use case was an RTOS with Tasks and each Task mapped to a thread - they wanted each Task to have its own individual TLS (i.e. not all vars in one place). Reason - security, but not obvious how this helps.

  • Question: Is this something that others would need too? Any more use cases?

    • Alternative is to put each task in its own ELF file and add a special loader.

  • Sam: Maybe CHERI and CHERIoT - they have compartmentalization, not threads, but need different TLS for each compartment.

  • => Peter will reach out to them.

QEMU plugin