[llvm-dev] A libc in LLVM

[Siva Chandra via llvm-dev]

Hello again,

I have now committed a proposal for this new libc:
https://reviews.llvm.org/D64939. This proposal is based on the charter
I shared previously (see below).

Though it is now committed, if there are any concerns still, I am open
to iterating until the community in general is satisfied with the
proposal.

Thanks,
Siva Chandra

On Fri, Jul 12, 2019 at 8:15 AM Siva Chandra <sivachandra at google.com> wrote:
> "llvm-libc" C Standard Library
> ========================
>
> llvm-libc is an implementation of the C standard library targeting C11
> and above. It also provides platform specific extensions as relevant.
> For example, on Linux it also provides pthreads, librt and other POSIX
> extension libraries.
>
> Documentation
> ============
>
> The llvm-libc project is still in the planning phase. Stay tuned for
> updates soon.
>
> Features and Goals
> ================
>
> * C11 and upwards conformant.
> * A modular libc with individual pieces implemented in the "as a
> library" philosophy of the LLVM project.
> * Ability to layer this libc over the system libc.
> * Provide C symbols as specified by the standards, but take advantage
> and use C++ language facilities for the core implementation.
> * Provides POSIX extensions on POSIX compliant platforms.
> * Provides system-specific extensions as appropriate. For example,
> provides the Linux API on Linux.
> * Vendor extensions if and only if necessary.
> * Designed and developed from the start to work with LLVM tooling and
> testing like fuzz testing and sanitizer-supported testing.
> * ABI independent implementation as far as possible.
> * Use source based implementations as far possible rather than
> assembly. Will try to “fix” the compiler rather than use assembly
> language workarounds.
>
> Why a new C Standard Library?
> =========================
>
> Implementing a libc is no small task and is not be taken lightly. A
> natural question to ask is, "why a new implementation of the C
> standard library?" There is no single answer to this question, but
> some of the major reasons are as follows:
>
> * Most libc implementations are monolithic. It is a non-trivial
> porting task to pick and choose only the pieces relevant to one's
> platform. The new libc will be developed with sufficient modularity to
> make picking and choosing a straightforward task.
> * Most libc implementations break when built with sanitizer specific
> compiler options. The new libc will be developed from the start to
> work with those specialized compiler options.
> * The new libc will be developed to support and employ fuzz testing
> from the start.
> * Most libc implementations use a good amount of assembly language,
> and assume specific ABIs (may be platform dependent). With the new
> libc implementation, we want to use normal source code as much as
> possible so that compiler-based changes to the ABI are easy. Moreover,
> as part of the LLVM project, we want to use this opportunity to fix
> performance related compiler bugs rather than using assembly
> workarounds.
> * A large hole in the llvm toolchain will be plugged with this new
> libc. With the broad platform expertise in the LLVM community, and the
> strong license and project structure, we think that the new libc will
> be more tunable and robust, without sacrificing the simplicity and
> accessibility typical of the LLVM project.
>
> Platform Support
> ==============
>
> llvm-libc development is still in the planning phase. However, we
> envision that it will support a variety of platforms in the coming
> years. Interested parties are encouraged to participate in the design
> and implementation, and add support for their favorite platforms.
>
> Current Status
> ============
>
> llvm-libc development is still in the planning phase.
>
> Build Bots
> =========
>
> Coming soon.
>
> Get involved!
> ===========
>
> First please review our Developer's Policy. Stay tuned for llvm-libc
> specific information.
>
> Design Documents
> ===============
>
> Coming soon.