What does “LLVM implementation of Libc” mean here? Does that just mean an implementation of libc maintained by the LLVM project?
Loved the third point in Rich's reply:
"there is tremendous value in non-monoculture of libc implementations, or implementations of any important library interfaces or language runtimes. Likewise there's tremendous value in non-monoculture of tooling (compilers, linkers, etc.). Avoiding monoculture preserves the motivation for consensus-based standards processes rather than single-party control (see also: Chrome and what it's done to the web) and the motivation for people writing software to write to the standards rather than to a particular implementation. A big part of making that possible is clear delineation of roles between parts of the toolchain and runtime, with well-defined interface boundaries. Some folks have told me that I should press LLVM to make musl the "LLVM libc" instead of whatever Google wants to do, but that misses the point: there shouldn't be a "LLVM libc", or any one library implementation that's "first class" for use with LLVM while others are only "second class"."
> any one library implementation that's "first class" for use with LLVM while others are only "second class"."
I agree with Zachary here. LLVM's really good at mixing and matching w/target libs IMO (and linkers too, while we're at it). FWIW lld and libc++/abi have been a part of the llvm project for a long time now and BFD ld and libstdc++ are still the defaults for the linux clang driver.
The notion that a LLVM libc would in some way make other libc's "second class" is completely unfounded. libc++ vs. libstdc++ is proof of this.
Odd that so much of the goals folks make involve building monocultures.
If you think about it, one of the reasons to avoid Monocultures is because it reduces your control, and that's often seen through being price gouged in some way.
The problem is that this requires the group controlling ecosystem to accurately follow the needs of the masses. If what they provide starts mismatching what people want, more and more people begin to be unhappy, and it's very easy for the goals of the public to misalign with the goals of the controlling group over time. Just because people seem to prefer it now doesn't mean they will a decade from now, but a decade of control can cause real problems when trying to make changes. It's very easy to get into a local maxima type situation, where it takes a lot of time and resources to just come to parity with an alternative, much less capitalize on where it can exceed the status quo.
Imagine a situation where Firefox didn't exist. Since all the other major browsers have moved to Webkit (or Webkit forked) engine, what would the cost be in time and effort of highly skilled people to make a browser engine from scratch? I'm not sure any project would succeed, or if it did, it might be a decade in the making.
People like ease of use, but people also really dislike being stuck without a choice. I think people realize this, which is why even though they often vote for convenience with their dollars, they also express a preference that alternatives exist, even if they don't use them, because they recognize both the benefit of having that option as well as the pressure it puts on their preferred choice.
I think if you ask, most iPhone users would say they prefer their current phone. I also think if you asked them if they think they would be better off without Android existing, they would say no, for exactly the reasons above; it makes Apple move forward with advancements, and it provides an alternative if they ever decide they really don't like something Apple is doing.
The C library provides implementations for the platform-neutral language functions like "open/read/write/close/ioctl/dup/dup2" and more.
Many implementations do have performance-critical parts be target-dependent and implemented in assembly. IIRC glibc has more of this than musl/newlib/bionic, but it's been a while since I last looked.
Then can't you just get the LLVM IR out of it using Clang?
For the most part, C is a much easier language to program in than the IR. The IR is also very unstable: it changes from release to release.
On macOS, you're really supposed to always dynamically link to the libSystem.dylib libc implementation, because the macOS kernel has subtle backwards-incompatible changes in the raw syscall interfaces on every macOS release (maybe even in point-release updates, I'm not sure). Go tried to have its own internal static libc replacement for macOS like it does for Linux, but just a year or two ago Go gave that up, and now dynamically links the macOS libc.
These are all syscall wrappers. They are present in libc but they are going to be very boring stubs that merely call into the kernel. (Also I don't think you can call them platform neutral or language functions as they are POSIX rather than being from the C standard...)
The more "implementation-heavy" parts of a libc... Things like stdio, string calls, malloc, ...
Some of them also have to translate between the userspace version of particular argument types and the kernel version, which don't always line up.
> you can implement it yourself via signals
It appears, that you are contradicting yourself. Either it is "bad idea" or it is easy to correctly implement by oneself, not both.
musl has well though-out implementation of pthread cancellation, so it is clearly doable, even if glibc developers have failed at it.
It's easy to correctly implement the parts that aren't just adding a call to pthread_testcancel to every single syscall wrapper, just reserve an RT signal and do your thread teardown when you receive it, using pthread_sigmask to implement enable/disable. It's just that it's just a terrible idea.
> is a giant minefield if you care about not leaking or deadlocking
Aren't these two in opposition?
Libc is the C standard library, and there are multiple implementations of it, e.g. glibc and musl. Clang does not include an implementation of libc, though it does have an implementation of the C++ standard library called libc++: https://libcxx.llvm.org/
It's not immediately clear to me why an LLVM implementation of the C++ standard library would be desirable while an implementation of the C standard library would be undesirable.
Worth noting the c++ standard library has had a lot of changes in recent years. libc has been hugely more stable in the same timeframe. (Notably there was C11, but the changes since C99 are not nearly what has been going on in c++ land.) The odds that whatever libc you already have is good enough are very high.