[llvm-dev] A libc in LLVM

Zachary Turner via llvm-dev
Mon, 24 Jun 2019 22:43:15 -0000

What do you expect the support for Windows to be?  Certainly, I don't
expect you to provide Windows support personally if you don't need it,
but given that LLVM supports Windows, it should at least be done in
such a way that the design lends itself to interested parties
contributing Windows support.

Currently clang-cl has several dependencies on having a Visual Studio
installation present on your machine, and one of these is because to
provide an implementation of the CRT (i.e. libc).  So having a libc
implementation which supports Windows and is compatible with MSVCRT
would be useful for people using clang on Windows as well.

On Mon, Jun 24, 2019 at 3:38 PM Jake Ehrlich via llvm-dev
<llvm-dev at lists.llvm.org> wrote:
>
> disclaimer: I work at Google so don't take my +1 as an independent vote
forward.
>
> We would like to use this on Fuchsia and I am particularly interested in
creating a dynamic linking library for ELF with Roland McGrath's guidance.
We spoke about creating a library for writing dynamic linkers internally and I
don't see why this can't be upstreamed.
>
> On Fuchsia we critically need support for AArch64; What do you expect to be
architecture dependent? I struggled to think of where the architecture and not
the operating system was the issue.
>
> On Mon, Jun 24, 2019 at 3:23 PM Siva Chandra via llvm-dev <llvm-dev at
lists.llvm.org> 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, 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:
>>
>>
>> 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.
>>
>> 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.
>>
>> 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.
>>
>> 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.
>>
>> The project should be an exemplar of developing with LLVM tooling. Two
examples are fuzz testing from the start, and sanitizer-supported testing.
>>
>>
>> There are also few areas which we do not intend to invest in at this
point:
>>
>>
>> Implement dynamic loading and linking support.
>>
>> 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?
>>
>>
>> Thank you,
>>
>> Siva Chandra and the rest of the Google LLVM contributors
>>
>>
>> _______________________________________________
>> LLVM Developers mailing list
>> llvm-dev at lists.llvm.org
>> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev