LLVM Embedded Toolchains Working Group sync up

Community
81

2025-06-19

Agenda

  1. Code reviews and RFC:

  2. Community:

    • Dev Meeting workshop(s) preparations.

Discussion

Includes (Simi)

  • Intent is to eliminate the copies of headers in multilibs.

  • Options: extend the multilibs yaml file or add the logic to the driver itself.

  • Adding config in the yaml keeps all logic in one place.

  • Petr: hardcoding looks almost like multiarch implementation (for which there is a convention alresdy) - will double check the multiarch support in baremetal, then respond to the RFC.

stdio implementation in LLVM libc (William)

  • Semihosting in Arm can be used to implement stdio - suggestions for the design?

  • Petr: this is in active discussion with libc team now: no concrete proposal yet, more a set of constraints.

  • This will be discussed in next libc meeting next week Monthly LLVM libc meeting

  • Will respond to the RFC main thing is: users of libc do not have to pay for what they are not using, e.g. if app only needs serial IO then it should not pull in FILE* subsystem. Even if FILE* is needed for compatibility, buffering can be on or off as an option to save space.

  • We need to define the progressive layers like for printf() with multiple levels of features and code size options. In this case, there could be room for integration with the compiler to pull in implementation based on format options - saves variants of prebuilt library variants needed.

  • William: The task at hand is to enable fprintf, std::cout

  • Petr: for the specific PR an option for stdin/stdout only can be possible without possibility to create additional files.

fstream support without filesystem (Petr)

  • As a follow up from last call, discussed in libc++ sync on 10-06-2025

  • The concern was for adding more carveouts will add a lot of complexity very quickly - more ifdefs, etc.

  • It was also noted that dependencies on file IO are all over the place, thus it is difficult to port libc++ new new platforms in general.

  • The proposal was to create a low level file system API like one exists for threading support. This API will need to be implemented for each target platform.

  • A side note, it would be great to be able to share threading API between C and C++ libraries. Same for file IO would be great too.

  • Overall suggestion was to work on enabling all of filesystem (even if parts are not supported on the target platform).

Threading in libc (William)

  • Question: How to run libc integration tests on an embedded target that does not support multithreading? There is a dependency on TLS.

  • => Bring this up in the next Monthly LLVM libc meeting

RISC-V GCC driver integration (Sam, Garvit)

  • Landed, some Fuchsia toolchain related testing issues are being worked on.

  • How to test the changes locally? There is an upstream bot. There is a CMake cache file in LLVM repo to do a local build as well. Garvit will coordinate with Petr.

Workshops in LLVM DevMeeting (Petr)

  • Waiting for the confirmation from organizers, 2 workshops requested: runtimes and embedded, asked to schedule them one after another.

RFC for CFI in assembly (Garvit)