LLVM-libc Roundtable Meeting

[michaelrj-google]

• TLS on embedded
  • Some projects expect it (Hexagon natively supports it)
  • Currently TLS is only available on linux with LLVM-libc
  • TLS is needed for errno, some startup code
  • You can do errno with a function call instead, but that’s generally slower.
  • Is TLS a platform generic interface?
    • Kinda, it is often simulated on embedded systems
  • Should we just have a switch to turn it off/on
  • This isn’t a priority until users are asking for it
• Tactical non-compliance of standards
  • Some embedded systems use 4 byte doubles
  • Some additions are very not zero cost
    • Locales are a major pessimization for string functions
    • Pthread cancellation also causes slowdowns on syscalls
    • Widechars can also be slow
  • Need to set up a page on what choices we’ve made, and where to go if you want to provide support for something
  • Need to participate in standards committees (WG14, Posix)
  • May want to support printf with floats (not doubles)
• Building Clang with LLVM-libc
  • It would be nice to have a statically linked clang
    • Some platforms have a slow libc, it would be nice to have a fast universal thing
  • Needed:
    • Pthreads, some other things
      • libc++ can use C11 threads instead so that might work
      • Petr Hosek added a flag to tell libc++ that you’re building with LLVM-libc
  • There is a list of PRs for what clang needs
    • The author dropped off, so we should look into finishing it.
  • For just libc++ the only thing left to turn on locales is “strftime”
    • Currently the _l functions ignore the locale since we’re just supporting the default C locale
• We need a target triple for LLVM-libc
  • Instead of “gnu” or “musl” use “llvm”?
    • So “x86_64-linux-llvm”
• C++ 20
  • Currently the codebase is mostly on C++17, with some C++20 files
    • Would like to match libc++’s language version, which is C++20
  • For this we need to increase our minimum clang version
    • The minimum clang version is currently set based on our buildbots, and some of them don’t have easy upgrade paths
    • We could build clang on these machines, but they’re very slow (e.g. arm32)
    • Want to move to emulators for targets where possible for ease of use.
  • Might want to use lit for testing, to match with libc++
    • Potential problem: libc++ has their own lit extensions
      • The extensions are useful so we may want to try to adopt them more widely
• Porting guides
  • Need to update the docs
  • Nick Desaulniers is already working on an i386 port so he can write about his experience
• Zephyr is an RTOS that is potentially interested in libc
  • The OS support is set up to work in a modular way (you can relatively easily add a new OS)
  • Zephyr would need their own folder within OSUtil
• Floating Point
  • Some users want speed over correctness, can we provide fast versions?
    • There’s some configuration options already, but we can do more work.
  • Vector math would be a separate library
  • Some people want alternate entrypoints for “fast” versions of functions
• Semihosting
  • Qualcomm is working on simulator, which needs something like semihosting
  • Currently there’s no direct semihosting support, there’s a significant amount of work to be done to get it working.
    • If people need it, now is the time to get involved. The FILE interface isn’t crystalized yet.
  • Other libc’s have a different way of handling the OS layer (e.g. libgloss)
    • We might want to do something different
• Dynamic Linking
  • When we have a loader, people will depend on our ABI being stable.
  • Will this support CREL?
    • Haven’t made any decisions yet
  • There’s work being done on a separate loader in Google, but it’s not necessarily ready for LLVM-libc
    • Work would need to be done to donate it.