<div dir="ltr">I agree with your point 1.<div><br></div><div>With regards to point 2, I think there's a difference between Fuchsia, which Google controls (where every check-in is authored by a Fuchsia eng and reviewed by another Fuchsia eng), and LLVM, which Google doesn't control.  There's also a difference between Google in general, and the Fuchsia project, which I'd summarize as simply: Google is not a monoculture.  Case in point: Jake, who works at Google, immediately countered Siva's suggestion that "<span style="color:rgb(0,0,0);font-family:Arial;white-space:pre-wrap">Support for more architectures" is not something Google intends to invest in, by pointing out his need for AArch64 support.  I work for Google too, and I personally need RISC-V support.  (Separately, I'm sorry to hear about your experience with Fuchsia's </span>musl fork<span style="color:rgb(0,0,0);font-family:Arial;white-space:pre-wrap">... though I've not worked on Fuchsia and have no knowledge of that situation and therefore won't say anything more about it.)</span></div><div><br></div><div>With regards to point 3, I agree with your points, in particular, I agree that it's important for there to be a variety of libc implementations.  But it seems to me that while gnu has both gcc and glibc, gcc doesn't require the use of glibc, and I would anticipate that clang would never require llvmlibc.  I would anticipate that a user would continue to have their choice of compiler, their choice of STL implementation, their choice of libc implementation.  To the extent that there would be a "library implementation that's first-class for use with LLVM", I think there already is: glibc.  But it would be better if there were two first-class implementations.</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, Jun 25, 2019 at 2:34 PM Rich Felker via llvm-dev <<a href="mailto:llvm-dev@lists.llvm.org">llvm-dev@lists.llvm.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On Tue, Jun 25, 2019 at 03:24:04AM +0000, Siva Chandra via llvm-dev wrote:<br>
> Hello LLVM Developers,<br>
> <br>
> Within Google, we have a growing range of needs that existing libc<br>
> implementations don't quite address. This is pushing us to start<br>
> working on a new libc implementation.<br>
> <br>
> Informal conversations with others within the LLVM community has<br>
> told us that a libc in LLVM is actually a broader need, and we are<br>
> increasingly consolidating our toolchains around LLVM. Hence, we<br>
> wanted to see if the LLVM project would be interested in us<br>
> developing this upstream as part of the project.<br>
> <br>
> To be very clear: we don't expect our needs to exactly match<br>
> everyone else's -- part of our impetus is to simplify things<br>
> wherever we can, and that may not quite match what others want in a<br>
> libc. That said, we do believe that the effort will still be<br>
> directly beneficial and usable for the broader LLVM community, and<br>
> may serve as a starting point for others in the community to flesh<br>
> out an increasingly complete set of libc functionality.<br>
> <br>
> We are still in the early stages, but we do have some high-level<br>
> goals and guiding principles of the initial scope we are interested<br>
> in pursuing:<br>
> <br>
> The project should mesh with the "as a library" philosophy of the<br>
> LLVM project: even though "the C Standard Library" is nominally "a<br>
> library," most implementations are, in practice, quite monolithic.<br>
> <br>
> The libc should support static non-PIE and static-PIE linking. This<br>
> means, providing the CRT (the C runtime) and a PIE loader for static<br>
> non-PIE and static-PIE linked executables.<br>
> <br>
> If there is a specification, we should follow it. The scope that we<br>
> need includes most of the C Standard Library; POSIX additions; and<br>
> some necessary, system-specific extensions. This does not mean we<br>
> should (or can) follow the entire specification -- there will be<br>
> some parts which simply aren't worth implementing, and some parts<br>
> which cannot be safely used in modern coding practice.<br>
><br>
> Vendor extensions must be considered very carefully, and only<br>
> admitted when necessary. Similar to Clang and libc++, it does seem<br>
> inevitable that we will need to provide some level of compatibility<br>
> with other vendors' extensions.<br>
><br>
> The project should be an exemplar of developing with LLVM tooling.<br>
> Two examples are fuzz testing from the start, and<br>
> sanitizer-supported testing.<br>
> <br>
> There are also few areas which we do not intend to invest in at this point:<br>
> <br>
> Implement dynamic loading and linking support.<br>
> Support for more architectures (we'll start with just x86-64 for simplicity).<br>
> <br>
> For these areas, the community is of course free to contribute. Our<br>
> hope is that, preserving the "as a library" design philosophy will<br>
> make such extensions easy, and allow retaining the simplicity when<br>
> these features aren't needed.<br>
> <br>
> We intend to build the new libc in a gradual manner. To begin with,<br>
> the new libc will be a layer sitting between the application and the<br>
> system libc. Eventually, when the implementation is sufficiently<br>
> complete, it will be able to replace the system libc at least for<br>
> some use cases and contexts.<br>
> <br>
> So, what do you think about incorporating this new libc under the<br>
> LLVM project?<br>
<br>
Since I have a little experience in this area, I'd like to chime in on<br>
it. :-) TL;DR I think it's a reall, REALLY bad idea.<br>
<br>
First, writing and maintaining a correct, compatible, high-quality<br>
libc is a monumental task. The amount of code needed is not all that<br>
large, but the subtleties of how it behaves and the difficulties of<br>
implementing various interfaces that have no capacity to fail or<br>
report failure, and the astronomical "compatibility surface" of<br>
interfacing with all C and C++ software ever written as well as a<br>
large amount of software written in other languages whose runtimes<br>
"pass through" the behavior of libc to the applications they host, all<br>
contribute to the scale of work, and of knowledge/expertise, involved<br>
in making something of even decent quality. (As an aside, note that I<br>
love to see hobby libc projects even if they have major problems, but<br>
that's totally different from proposing something that lots of people<br>
will end up stuck using.)<br>
<br>
Second, corporate development teams are uniquely qualified to utterly<br>
botch a libc, yet still push it into widespread use, and the cost is<br>
painful compatibility hacks in all applications. Apple did this with<br>
their fork of BSD libc code. Google has done it once already with<br>
their fork of musl in Fuchsia -- a project which I contributed<br>
significant amounts of free labor to in terms of tracking down folks<br>
for license clarification their lawyers wanted, only to have them<br>
never bother to ask me why technical things were done they way they<br>
were before making random useless and broken changes in their fork. A<br>
corporate-led project does not have to answer to the community, and<br>
will leave whatever bugs they introduce in place for the sake of<br>
bug-compatibility with their own software rather than fixing them.<br>
<br>
Third, there is tremendous value in non-monoculture of libc<br>
implementations, or implementations of any important library<br>
interfaces or language runtimes. Likewise there's tremendous value in<br>
non-monoculture of tooling (compilers, linkers, etc.). Avoiding<br>
monoculture preserves the motivation for consensus-based standards<br>
processes rather than single-party control (see also: Chrome and what<br>
it's done to the web) and the motivation for people writing software<br>
to write to the standards rather than to a particular implementation.<br>
A big part of making that possible is clear delineation of roles<br>
between parts of the toolchain and runtime, with well-defined<br>
interface boundaries. Some folks have told me that I should press LLVM<br>
to make musl the "LLVM libc" instead of whatever Google wants to do,<br>
but that misses the point: there *shouldn't be* a "LLVM libc", or any<br>
one library implementation that's "first class" for use with LLVM<br>
while others are only "second class".<br>
<br>
So, in summary:<br>
<br>
Point 1 is why making a libc for real-world use is not to be taken<br>
lightly.<br>
<br>
Point 2 is why, if it is done, it shouldn't be a Google project.<br>
<br>
Point 3 is why there should not be an "LLVM libc".<br>
<br>
Hope this is all helpful.<br>
<br>
Regards,<br>
<br>
Rich<br>
_______________________________________________<br>
LLVM Developers mailing list<br>
<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a><br>
<a href="https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev" rel="noreferrer" target="_blank">https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev</a><br>
</blockquote></div>