[llvm-dev] A libc in LLVM
Jake Ehrlich via llvm-dev
llvm-dev at lists.llvm.org
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>
>> disclaimer: I work at Google so don't take my +1 as an independent vote
>> 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
> Just for my knowledge, why is answering these questions at a general level
>> 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
>>> 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
>>> There are also few areas which we do not intend to invest in at this
>>> Implement dynamic loading and linking support.
>>> Support for more architectures (we'll start with just x86-64 for
>>> 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
>>> Thank you,
>>> Siva Chandra and the rest of the Google LLVM contributors
>>> LLVM Developers mailing list
>>> llvm-dev at lists.llvm.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the llvm-dev