llvm dev - Jun 2019 - A libc in LLVM

Hi

I find it interesting that a reimplementation of libc is being
discussed without clearly stating the differences and benefits of the
new implementation.

Or did I miss the discussion about the differences and benefits?

Sincerely
Jan

On Wed, Jun 26, 2019 at 6:48 AM Jan Ziak via llvm-dev <
llvm-dev at lists.llvm.org> wrote:
> Hi
>
> I find it interesting that a reimplementation of libc is being
> discussed without clearly stating the differences and benefits of the
> new implementation.
>
> Or did I miss the discussion about the differences?

I can’t speak for Siva’s and/or Google, but two obvious differences that
come to mind for me personally are:

1) the license

2) there is currently no existing open source implementation of libc for
Windows that works with native Windows / MSABI toolchains.  clang on
Windows, for example, has a hard dependency on a full visual studio
installation for exactly this reason.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20190626/fe61839f/attachment.html>

On Wed, Jun 26, 2019 at 8:49 AM Jan Ziak via llvm-dev
<llvm-dev at lists.llvm.org> wrote:
>
> Hi
>
> I find it interesting that a reimplementation of libc is being
> discussed without clearly stating the differences and benefits of the
> new implementation.
>
> Or did I miss the discussion about the differences and benefits?
Siva touched on them at the top of his message, but it maybe got lost
a bit in the ensuing discussion.  Plus the differences and benefits
will to some extent depend on where people want to go with it.

As someone who has spent the last several years hammering the round
peg of glibc into the square hole that is Google production
infrastructure (it does work, breadcrumbs to the glibc branches here -
https://sourceware.org/glibc/wiki/GlibcGit/google_namespace ), I find
a couple opportunities especially appealing:

1) Static linking, which opens up opportunities for whole-program
analysis.  In theory, one could do this with glibc, but even aside
from the LGPL issue, the code is built to present a versioned-symbol
ABI.  Imagine being able to trace all the way to the bottom of a
printf call, and only incorporate the bits that you actually use, or
being able to elide locks in a known safe zone.

2) Updated build machinery and coding style.   I'm sure it's urban
legend that glibc was written as a test case for every GNU Make
feature :-) but its makefiles are pretty intricate, there are a bunch
of cases where chunks of code are synthesized by make rules, and a
bunch more where important code is in the bodies of multi-page
multi-level C macros, in the best programming style of the 1980s.