Monthly LLVM libc meeting

Runtimes C
12

Notes from today’s meeting:

  • Hand In Hand
    • Link to RFC: [RFC] Project Hand In Hand (LLVM-libc/libc++ code sharing)
    • What are the goals?
      • We want to close the gap on libc building for libc++
      • We also want to stop duplicating code between the projects
    • Libc++ currently depends on a conforming libc
      • This may be like adding a new libc that it supports
      • Some functions will probably have options to use the system libc, but others may not require this
        • Calling ctype functions on the default c locale is the same in all libcs
        • Similarly, string to float should always give the same result
    • Currently, libc++ can’t be built fully on top of LLVM-libc
      • Embedded targets and some Fuchsia uses
    • The new design would change the libc surface that libc++ uses
      • Some platform independent functions would always come from LLVM-libc
      • Some other functions would still come from the public libc interface
    • This would allow us to share code that can’t go through the public interface
      • The from_chars interface is similar to the strtod interface, but from_chars can’t easily call strtod
    • Libc++ already depends on other directories
      • Specifically libcxxabi and libunwind
      • Adding a new interface will hopefully not be too large
    • Some of the duplicated interfaces are in installed headers
      • We need to (at least initially) avoid touching those since we don’t want to leak the libc internal interface
    • Build system integration
      • We need to be careful of the case where users take just individual folders for individual libraries
        • Examples:
          • Fuchsia uses libc as an individual folder
          • Pigweed uses libc and libcxx as individual slices
          • Chromium builds libcxx as part of chromium
        • We’ll need to decide on include path policies, and warn downstream users so that they can update their build systems
      • Officially libc++ doesn’t support users who take just an individual folder from the monorepo
        • Their policy is basically just copy any extra folders too
    • The existing libcxxabi interface is problematic
      • There is automated code copying, and some parallel headers
      • We don’t want our project to end up like that
    • The libc++ project has previously tried to share code that shows up in the installed headers
      • It was a lot of effort, there’s a lot of macros and other specific code style choices that need to be kept in sync
    • Shared underlying API design
      • Mutexes in libc currently have a flag to mark it as recursive or not
        • This means that lock/unlock always has a branch to check
      • Libc++ has two different types for mutex and recursive mutex
        • Since they sit on top of libc, they have to use the mutex type with flag under the hood, causing performance bottlenecks
      • A shared underlying interface could avoid these bottlenecks
        • Louis Dionne would be very interested in this
    • If the existing C interface is designed in a way that doesn’t work well with C++, it is possible, though difficult, to change the C standard
      • Android went through the process to make this change with pthread clock waits, and got changes in bionic+glibc and libc++ and POSIX
      • the specific “this solves an impedance mismatch problem between libc and libc++” use case was sufficiently obvious+convincing that it “only” took about a year start to end — everybody “got it”.
  • Petr Hosek is working on porting code for a baremetal codebase
  • Nick Desaulniers: libc and libc++ interface layer
    • Libc++ currently needs ~80 symbols that LLVM-libc doesn’t provide
    • Carve outs can remove some of these, but not all
  • SchrodingerZhu Macro policy inside of LLVM-libc
    • Existing:
      • Headers in libc/include have dependencies on macros and types
        • Some macros are defined in UAPI headers, but some we provide ourselves
        • Some macros are defined in llvm-libc-macros, some in API.td
      • For internal usage
        • Current use is split between using the public header vs depending on our internal header directly
    • Future
      • We should try to provide a complete set of macros for C23
        • We may need to use linux UAPI headers for specific macros/types
          • But also some are unusable since they don’t match the userspace interface
        • Linux headers are mostly stable between versions
        • Posix headers often have a lot of implementation defined pieces, we’ll need to keep that in mind
      • For internal usage
        • Types and macros should always be defined in llvm-libc-types/llvm-libc-macros
        • Ideally headergen would only be used for functions
  • Nick Desaulniers: Lint rules
    • We have a rule that checks if a header comes from the system
      • We need to clean up code that currently is doing this