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.
5 Likes