[llvm-dev] A libc in LLVM

Tue Jun 25 16:05:41 PDT 2019

Syscalls are operating system specific and architecture dependent so I
think we'll want an abstraction layer around the fundamental operations the
syscalls support anyway. Some things like open aren't even syscalls on all
operating systems. There might be a generic syscall layer added that would
be architecture and not operating system specific but even on x86_64 there
are two different ways to do syscalls I think. Loading, startup, and
linking are all both format and operating system specific and a few of
these details involved are determined by the architecture but they're
trivially abstracted away.

why is answering these questions at a general level important?

Because I wanted to make sure I understood the direction and the
restriction stated. The restriction on what architecture will be used
without stating a restriction on the operating system seemed like an odd
statement. I'd very much like operating system abstractions to be
considered right out of the gate and this seems like a bigger issue than
the architecture to me.

On Tue, Jun 25, 2019 at 3:47 PM Siva Chandra <sivachandra at google.com> wrote:

> 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/e8779abf/attachment.html>