[llvm-dev] A libc in LLVM

[Siva Chandra via llvm-dev]

On Mon, Jun 24, 2019 at 3:37 PM Jake Ehrlich <jakehehrlich at google.com>
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.
>

If dynamic linking support is added in a "as a library" fashion, so that it
can easily be excluded if not required without affecting the rest of the
system, I do not see any problems adding it.


> 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.
>

I think syscalls are an example of being architecture specific? And, items
like program startup and PIE loader are operating system/exe format
specific?

Just for my knowledge, why is answering these questions at a general level
important?


> 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:
>>
>>
>>    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.
>>
>>
>> There are also few areas which we do not intend to invest in at this
>> point:
>>
>>
>>    1.
>>
>>    Implement dynamic loading and linking support.
>>    2.
>>
>>    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
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20190625/64c56a75/attachment-0001.html>