LLVM Embedded Toolchains Working Group sync up

Community
80

2025-05-22

Agenda

  1. Code reviews and RFC:

    • TBD: please add your links as comments.

  2. Updates:

    • fstream support in embedded libc++ without full filesystem support discussed here: we keep getting requests from Arm Compiler users to re-enable this in ATfE. What are community thoughts?
    • –stdlib option (discussed in LLVM libc sync) next steps. We expect to have multiple libraries in ATfE later, so are interested in having a standardized way of selecting one. Current option is a config file that points the --sysroot to the folder which provides the library builds.
    • Duplicated compiler_rt/picolibc builtin symbols issue solved: LLVM PR and ATfE PR.

  3. Community:

  4. Other

    • Multilibs layout for includes: fixed vs configurable.
    • ATfE GitHub CI binaries available for Linux, Windows is coming.

Discussion

Reviews

Nothing to highlight.

fstream support without filesystem

  • Petr: We also see a need in something finer grained, e.g. serial IO instead of FILE*, would be useful to have a carve out for such a scope. Next step up could be e.g. stdin/stdout/sterr only as static files. There is a fear that it will increase complexity. Would be useful to have at least one additional carve out - may be difficult to provide a good name for it to explain what it is.

    • → bring this in next libc++ sync meeting on 10th of June.

    • → also there are some patches for review form Petr to make the discussion more concrete

  • Peter: We may also think about an interface to provide functions to link for the whole filesystem even if most of them would be stubs. The GLIBC mechanism of gnu_warning is not supported in LLD.

    • Daniel: Need to be sure that the stub is not used at run time, otherwise can be very misleading and lead to surprising run time error.

stdlib command line option

  • Petr: The main question is how cold it work exactly, e.g.:

    • Fixed hardcoded enum of known libc’s, e.g. like unwind libraries, compiler_rt vs libgcc, etc.

    • Extensible system, e.g. a yaml config file with details - fear that it can grow into GNU spec files or similar complexity.

    • Something in between: harcode most common + a fall back for the rest.

    • → Need to discuss with a proper RFC.

  • Peter: Is this a niche for embedded toolchains only? Dedicated target triples exist for muslc and glibc.

  • Michael: We observed that file organization is relatively stable, so we can have an expectation/interface defined. Can be a custom option that point to “standard” layout.

    • Petr: The issue is with non-standard aspects, e.g newlib requires libgloss to be added.

      • Peter: For some particular issues like this, linker script when a library includes for more libraries can be used.

  • → Arm team will think about an RFC

multilibs includes

  • Peter: large number of binary lib variants cause a lot of duplication of headers. The idea is to provide one headers set with multiple binaries.

  • Petr: There is supported in libc++ (e.g. Fuchsia) for include for common headers plus a target directory after the triple with __config_site file. Multiarch and multilib are supported: can have directories per multilibs. There may be no docs for this though. The driver is aware already. There are also sanitizers specific variants.

    • This approach is not supported for libc, because the headers are generated, idea: there are internal headers that are not generated, thus a similar scheme can be used with static headers.

  • Peter: For newlib and libc there is only one file that is generated and is different.

    • Idea is to extend the multilibs yaml file with additional include paths.

    • → Arm team will send an RFC.

    • Next level: layering of binary variants, e.g. optimized binaries first, then generic.

DevMeeting 2025

  • Petr will propose embedded toolchain workshop. Suggestion is to keep mostly the same format. Questions:

    • Length: half or full day? Last year attendees asked for a full day workshop - there was a lot of content.

    • Do we need a dedicated libc workshop or include it into the embedded one? Can try to ask to schedule them at different times.

    • Can be “runtimes” workshop i.e. include libc and libc++

      • → Michael to write a proposal

    • → Agreed to submit half-day embedded and half-day runtimes proposals and ask to schedule them at different, best adjacent, times.

CFI directives for inline asm

  • Petr: inline asm for interrupt handling is usually written manually and does not provide DWARF directives, thus bad debugging experience. Idea: a feature in the compiler to check CFI directives and may be even generate them later. GCC added this recently - tries to generate, but still very limited.

    • Someone is prototyping this now. RFC is coming soon.

  • Is there any prio art?

    • Peter: there was sucn a request for armasm, we tried to implement, but did not succeed, Peter to find some records of issues encountered. Mostly a lot of corner cases that cannot be resolved automatically, e.g. when the SP is changed in the code.

embedded security measures

  • Todd: What are approaches to adding checks for security against physical tempering.

  • Peter: there was experience adding NOPs that a later pass can override. Tend to be very specialized and secret, thus not upstreamable.