Notes from the LLVM Libc roundtable (original) (raw)

October 12, 2023, 9:06pm 1

We had a roundtable discussion on the status of the libc project at the US developer meeting. Here are my (lightly edited) notes from the discussion:

• LLVM’s libc for embedded
  • Fuchsia has tried it, but hasn’t shipped it yet.
  • It’s comparable to newlib in code size, especially if you set the flags to shrink printf.
  • Right now it’s in a spot where you need to just try it and file bugs.
  • Every product is different in embedded, and has different requirements.
  • We should set up a guide for how to build for embedded
    * Upstream there are two configs relevant to embedded, linux and baremetal.
    * They’re just starting points, you may need to customize for your specific target.
    * Pigweed/Fuchsia use their own build system (GN)
  • Right now libc headers are generated using a tablegen based tool (called headergen)
    * Generated headers are very nice, since you can exclude functions that don’t work
    * Problem: It’s got a dependency on tablegen, and it’s awkward to distribute.
    * Many users want to take just the libc directory and build from there.
    * We’d like to switch to a more standalone solution, but not much work has been done yet.
  • What about the startup sequence?
    * We provide startup code for linux, but not embedded right now
    * Embedded systems are highly variable, so it’s not really practical to provide a generic solution in the library.
    * It would be good to have an example implementation for some arm32 embedded system, so that others can modify/reconfigure it for their own target.
• What parts of the libc are missing currently?
  • Widechar, locale, some math functions (some double precision, most long double), a dynamic loader.
  • There are also many posix or other extension functions we haven’t implemented yet.
  • You can’t currently build libc++, since it assumes that every part of the libc is provided.
    * I haven’t tried using the libc++ carve outs to disable parts, it may be possible to build libc++ with no locales on LLVM’s libc.
• External testing
  • There are perennial and supertest as standard conformance tests
    * They mostly cover the interface/standard, whereas our tests are more about functionality.
• Math functions:
  • The primary target is accuracy, and speed is secondary.
  • That’s not to say it’s slow, it is often faster than glibc, but it is always accurate.
  • Single precision functions are done, double precision functions are ongoing.
• Future work:
  • We should set up github milestones to track progress, especially to enable external contributions.
  • There aren’t a lot of people working on the project so progress is slow, but you can help!
• Sanitizers:
  • We support them!
  • We have found some bugs with them, especially with fuzzers.
  • There are some functions that have unsafe implementations, such as strlen.
    * The fast way is to read several bytes at a time, but that’ll read off the end of the string.
    * We avoid sanitizing these functions in unsafe mode.
• Why does Fuchsia use their hybrid libc?
  • Their libc is some musl and some LLVM libc.
  • Mostly cleanliness, readability, and keeping things updated.
    * The version of musl is very outdated, and would be hard to update.
• How does LLVM’s libc do configurability?
  • Some parts are provided with compile options, like in printf you can use your system file but it loses you some optimizations.
  • If you want to provide your own version of a function, you can just remove it from the build list, then link your own.
  • The design of LLVM’s libc is more like a libc creation kit, each function can be included independently.