Monthly LLVM libc meeting

Runtimes C
36

Notes from today’s meeting:

  • Templating the printf writer/scanf reader
    • Important for the GPU build that the printf code is header only
    • Also useful for baremetal
    • Planning to provide static dispatch and dynamic dispatch
    • Adding printf for baremetal unblocks libcxx streams on baremetal
    • The current printf templating interface is different from the proposed scanf implementation
      • It also bloats the .a a bit, but not a final binary since the multiple copies of the template are all identical, just in every printf object file
  • Bazel build updates
    • We’d like to have fullbuild in bazel, so we’re working on that
  • Aliasing function updates
    • Is it okay for two different libc functions to have the same address?
    • There was some confusion around the specific formal wording in the C Standard, but it seems like it’s getting clarified that having a function be an alias of another is fine.
    • In older versions of the C Standard it was clear it was fine, more recent versions made it less clear, new proposal to clear it up
    • C issue 1003: Linkage between library functions
  • Finer control over FMA instructions on arm
    • Cortex m33 has float hardware but not double hardware, so we’ll need to update the build system to understand having hardware fma for float but not double.
    • Will need to extend this to other functions that may or may not have hardware.
    • Might also be relevant for RISC-V, some chips there also have float and not double (the f extension not the d extension)
  • GSOC proposal got a lot of interest
    • Need to file more good first issues, since we’re running out of math functions to implement
  • C++20 by default
    • Some buildbots are still running older clang, can probably push some of them forwards.
    • There’s also a project to upgrade and combine the libc buildbots with the other LLVM runtimes buildbots
    • We’re also looking into more QEMU testing for RISC-V and other harder to set up architectures
      • QEMU baremetal is tricky, since QEMU doesn’t support every board.
      • The RVOS team has looked at QEMU a bit, but for a lot of their testing they just have Raspberry Pi Picos.
      • ARM also provides an emulator for its boards
      • Need some amount of hardware for performance testing since emulation isn’t useful for that.
    • If we want to confidently use C++20 we want to be at clang 17 at least.
      • There’s also support issues between clang and gcc. We may need to limit which features we allow.
      • Also if we require at least clang 17 then some users won’t have a recent enough compiler.
        • Then again libc++ already requires very recent compilers
      • If we want to share code with clang/LLVM then we need to make sure our code can be compiled with their same requirements.
    • Running tests in overlay mode under QEMU should be possible now
    • Look into what ARM does for their CI
      • Also the emulation for embedded targets tends to be a whole board instead of just the CPU
  • Clang option for libc selection
    • Clang currently has two baremetal toolchain targets: RISCVToolchain and BareMetal.
    • BareMetal doesn’t assume anything
    • RISCVToolchain assumes that there’s an existing gcc installation
      • It also assumes newlib as its libc
    • We need some way to select other libcs
      • We could use heuristics to automatically detect which libc you’re using
      • We could also add a selection flag similar to what libc++ has
    • Need to figure out how we want to resolve this
      • Roland:
        • Having a switch seems like the simplest choice since the user should be able to choose their libc
        • There can also be heuristics for selecting the default for the switch
      • Alexey:
        • Could also use the target triple to select the libc. The last part of the triple describes the ABI which ~= the libc.
        • Having an explicit flag would be very helpful, regardless of how it’s passed.
      • Ross:
        • A bunch of tools already assume that using the target triple lets them select the libc, so we might need to support that anyways.
      • Triples also aren’t really three anymore and the ordering can be confusing.
      • Peter:
        • The ARM toolchain already has some libc selection mechanism, it defaults to picolibc but has an option for newlib.
        • If it’s an explicit compiler flag it’s easier to put into the build system
        • There are also many embedded runtimes that are a pair of libraries, one for hardware abstraction and one that’s the main libc.
      • Flag naming:
        • “–libc=” makes sense, it matches “–nolibc” and parallels “–stdlib=” and “–nostdlib++”
  • UEFI work
    • Headers merged, working on cmake/entrypoints.
    • Next step is testing via QEMU
    • Should headers have mixed case names?
      • The UEFI spec explicitly has mixed case names already.
    • Also how will new headers not described by a standard be named?
      • Need to make sure to keep the extension headers separate from the standard headers
    • There’s one main UEFI header which splits out into smaller headers internally
    • If we’re defining a new ABI we should make sure to design it intentionally.
    • Before a new target can be added it has to have a plan for buildbots
  • Code sharing between libc and libc++
1 Like
LLVM Embedded Toolchains Working Group sync up
LLVM Embedded Toolchains Working Group sync up
LLVM Embedded Toolchains Working Group call this Thursday, May 22
[RFC] Add command line option for selecting C library