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

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.

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 -
GlibcGit/google_namespace - glibc wiki ), 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 :slight_smile: 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.