[llvm-dev] A libc in LLVM

[Siva Chandra via llvm-dev]

On Mon, Jun 24, 2019 at 3:45 PM Finkel, Hal J. <hfinkel at anl.gov> wrote:

> 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.
>
I am of the opinion that modularity should be as fine-grained as possible.
For example, one should be able to pick and package individual functions
into a libc as suitable for their platform.
That said, I am open to other ideas you might have about modularity. I am
also open to getting convinced that function level granularity is an
overkill.

>
>    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 listllvm-dev at lists.llvm.orghttps://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/20190625/7a9ce6df/attachment.html>