[llvm-dev] A libc in LLVM

[David Jones via llvm-dev]

On Fri, Jul 12, 2019 at 9:15 AM David Greene via llvm-dev <
llvm-dev at lists.llvm.org> wrote:

> Aaron Ballman via llvm-dev <llvm-dev at lists.llvm.org> writes:
>
> >> * Ability to layer this libc over the system libc.
>
> Echoing others, this seems dubious to me.  Why not build up small pieces
> at a time and write tests for them?  This library doesn't need to
> support all existing programs out of the gate.


I can *definitely* appreciate that not everybody wants a
Frankenstein's-monster-of-a-library.

For what it's worth... for our usage (within Google, and specifically,
within the production fleet), it is much more imperative to show broad
usage sooner rather than later. It might make more sense from this
perspective: we want to develop in the open (i.e., not just throw some code
over the fence when we're "done enough"); and we want it to be of high
enough quality that others might use it. In order to do this, we actually
need to deliver the "low-hanging fruit" first, because that is a large part
of what justifies the rest. Realities being what they are, it would be a
non-starter to have no such facility; and it would be somewhat antithetical
to carry out such a substantial part of our development effort behind
closed doors.


> I dont't think libc++
> layered on top of existing standard C++ libraries, so why would libc
> need to?


There will almost certainly be other platforms where a top-to-bottom
implementation would be impossible to implement. Not because of the libc
parts, but functionality that -- for whatever reason -- is only available
in a library that is also a libc.

(Examples off the top of my head: sandboxed environments, platforms which
only allow syscalls through a provided DSO, or platforms which embed some
critical functionality within the same binary blob as a vendor-provided
libc.)


> >> * Provide C symbols as specified by the standards, but take advantage
> >> and use C++ language facilities for the core implementation.
>
> Does this mean C programs would require a C++ runtime?  If not, how will
> the project ensure that?
>

Shooting from the hip: no. Turning off exceptions, RTTI, and static
initializers (i.e., things which require a guard variable) is probably
enough to obviate the need for the runtime.

Of course, this raises platform-specific concerns.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20190712/fe9161c2/attachment.html>