LLVM Embedded Toolchains Working Group sync up

Community
78

2025-03-27

Agenda

  1. Please highlight any code reviews or RFCs that you want to discuss.

  2. Petr: Qualcomm RISC-V toolchain driver merge into the Baremetal driver.

  3. Michael: definition of -ffreestanding https://github.com/llvm/llvm-project/pull/132232#issuecomment-2741887387

  4. Peter: Interest around LLVM support for Embedded Linux, e.g. Yocto, and other RTOSes.

  5. Status updates on the previous topics.

Discussion

Petr: Qualcomm RISC-V toolchain driver merge into the Baremetal driver

  • Garvit: Links:

  • RISC-V driver assumes presence of GCC installation, newlib, libstdc++, … otherwise very similar to the Baremetal driver, thus a lot of code duplication.

  • Also this will make the Baremetal driver more uniform with other drivers in the order of command line options generated for the linker.

  • Qualcomm started working on this, there are many patches, asked to breakup even further to split into independent logical changes.

  • Mostly two reviewers now (Petr and Fangrui) - anyone who has an opinion please reach out.

  • Expect changes and churn in the baremetal driver in a few weeks from now.

  • Peter: We can try to apply locally and see if anything breaks in ATfE. Arm GNU Toolchain installation can be used for testing.

  • Update from the llvm libc meeting last week (Monthly LLVM libc meeting - #36 by michaelrj-google) regarding a comment from the review: adding a command line option to select the C lib to use - people in the call have been supportive. Needs an RFC to define the details. May obsolete dependency on GCC installation in the future.

    • Observation: There are many more C libraries than C++ libraries including proprietary ones - the option may need to be open-ended, not a fixed list.

    • May need to work a bit like a config file/linker script to configure related libs, e.g. libgloss in addition to newlib.

Michael: Definition for freestanding

  • https://github.com/llvm/llvm-project/pull/132232#issuecomment-2741887387

  • In the C standard freestanding implementation has a very limited list of headers, apparently people want much more from the library in freestanding (embedded) mode. Can we provide feedback to the C standard committee to extend?

  • The C standard may define the minimum implementation, but do not limit to only those headers, so implementations can add more.

  • Note: there was a big discussion about C++ re-definition of freestanding, here is a rather old roadmap P2268R0: Freestanding Roadmap, need to check if anything was accepted into recent C++ standards.

  • Peter: Rust did it in a different way by splitting the core and heap related parts.

  • Petr: freestanding is too coarse grained, just binary - projects need more levels of support

  • LLVM libc++ does not have proper support for freestanding now, instead there are multiple flags to turn on/off different features. For libc++ freestanding support effort is only about standards compliance - individual flags fit real usage better. Similarly, libc may need more switches/options to configure.

  • This does make sense to raise to the std committee - Aron may be a good contact, he joins the libc meetings.

Peter: Embedded Linux/RTOS

  • We are looking into Embedded Linux for FuSa, e.g. automotive use cases.

  • Embedded Linux app development is mostly usual Linux development, so may not be very close to embedded topics discussed in this call.

  • FuSa qualified tools require pre-qualified binaries including for libraries - cannot patch sources.

  • Yocto is one of Embedded Linux distro builders: it downloads clang source release, applies ~30 patches, builds the toolchains and uses it for the rest of build via meta-clang: GitHub - kraj/meta-clang: Clang C/C++ cross compiler and runtime for OpenEmbedded/Yocto Project, the patches are under https://github.com/kraj/meta-clang/tree/master/recipes-devtools/clang/clang

  • In order to get a binary qualified toolchain, the patches either need to be upstreamed or there should be enough ways to configure clang - Yocto is based on OpenEmbedded that uses different conventions for where libraries and other dependencies are placed, thus a lot of small workarounds.

  • Any interest in the embedded LLVM community?

  • Petr: Yes:

    • Interested in different approaches to organization of libs/runtimes/etc

    • Recently was contacted by Android Auto team to talk about FuSa in auto space. Among other things, auto team is interested in tooling provided by LLVM, e.g. static analysis, tidy, clangd, … - would these be usable for auto specific checks? Or even embedded specific checks vs POSIX?

  • Peter: We will need to think about it more and come up with an RFC.

  • Petr: What C libraries is Yocto using? maybe an interesting use case for LLVM libc to target Yocto.

    • Peter: It is configurable: glibc, musl as main could be uclibc. Can be different for FuSa where they may need to use a pre-qualified binary library.

  • Michael: FYI an existing Yocto build bot for RISC-V Buildbot

  • Peter: Qualification is expensive because of required test coverage - if upstream testing is sufficiently good, would be useful and help the community.

Petr: llvm libc update

1 Like