[llvm-dev] A libc in LLVM

Finkel, Hal J. via llvm-dev
Mon, 24 Jun 2019 22:45:22 -0000

On 6/24/19 5:23 PM, Siva Chandra via llvm-dev wrote:

Hello LLVM Developers,


Within Google, we have a growing range of needs that existing libc
implementations don't quite address. This is pushing us to start working on
a new libc implementation.


Informal conversations with others within the LLVM community has told us that a
libc in LLVM is actually a broader need,


+1 - This has also been my experience: Many people over many years have
expressed a desire to have a libc has part of the LLVM project. It is currently
a large gap in our LLVM toolchain offering. Moreover, from the standpoint of my
organization, an LLVM libc could provide benefits on both production platforms
and research/experimental hardware.


and we are increasingly consolidating our toolchains around LLVM. Hence, we
wanted to see if the LLVM project would be interested in us developing this
upstream as part of the project.


To be very clear: we don't expect our needs to exactly match everyone
else's -- part of our impetus is to simplify things wherever we can, and
that may not quite match what others want in a libc. That said, we do believe
that the effort will still be directly beneficial and usable for the broader
LLVM community, and may serve as a starting point for others in the community to
flesh out an increasingly complete set of libc functionality.


We are still in the early stages, but we do have some high-level goals and
guiding principles of the initial scope we are interested in pursuing:


  1.  The project should mesh with the "as a library" philosophy of
the LLVM project: even though "the C Standard Library" is nominally
"a library," most implementations are, in practice, quite monolithic.

  2.  The libc should support static non-PIE and static-PIE linking. This means,
providing the CRT (the C runtime) and a PIE loader for static non-PIE and
static-PIE linked executables.

  3.  If there is a specification, we should follow it. The scope that we need
includes most of the C Standard Library; POSIX additions; and some necessary,
system-specific extensions. This does not mean we should (or can) follow the
entire specification -- there will be some parts which simply aren't worth
implementing, and some parts which cannot be safely used in modern coding
practice.

  4.  Vendor extensions must be considered very carefully, and only admitted
when necessary. Similar to Clang and libc++, it does seem inevitable that we
will need to provide some level of compatibility with other vendors'
extensions.

  5.  The project should be an exemplar of developing with LLVM tooling. Two
examples are fuzz testing from the start, and sanitizer-supported testing.


Great.



There are also few areas which we do not intend to invest in at this point:


  1.  Implement dynamic loading and linking support.


It will be useful to have a design document that describes the kind of system
and capabilities that you're targeting, and then we can discuss how the libc
might have a modular design that can be adapted for other use cases. I mention
modularity because, for example, we have accelerator hardware and various kind
of low-variability/embedded environments where many, but not all, POSIX/libc
capabilities make sense.


  1.  Support for more architectures (we'll start with just x86-64 for
simplicity).


For these areas, the community is of course free to contribute. Our hope is
that, preserving the "as a library" design philosophy will make such
extensions easy, and allow retaining the simplicity when these features
aren't needed.


We intend to build the new libc in a gradual manner. To begin with,  the new
libc will be a layer sitting between the application and the system libc.
Eventually, when the implementation is sufficiently complete, it will be able to
replace the system libc at least for some use cases and contexts.


So, what do you think about incorporating this new libc under the LLVM project?


This is something that I'd like to see.

 -Hal



Thank you,

Siva Chandra and the rest of the Google LLVM contributors




_______________________________________________
LLVM Developers mailing list
llvm-dev at lists.llvm.org<mailto:llvm-dev at lists.llvm.org>
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev


--
Hal Finkel
Lead, Compiler Technology and Programming Languages
Leadership Computing Facility
Argonne National Laboratory
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20190624/0dbdb594/attachment-0001.html>