[llvm-dev] A libc in LLVM
Andrew Kelley via llvm-dev
llvm-dev at lists.llvm.org
Wed Jun 26 09:02:40 PDT 2019
On 6/24/19 6:23 PM, Siva Chandra via llvm-dev wrote:
> Within Google, we have a growing range of needs that existing libc
> implementations don't quite address.
> To be very clear: we don't expect our needs to exactly match everyone
> else's -- part of our impetus is to simplify things wherever we can, and
> that may not quite match what others want in a libc.
> There are also few areas which we do not intend to invest in at this point:
> Implement dynamic loading and linking support.
> Support for more architectures (we'll start with just x86-64 for
> So, what do you think about incorporating this new libc under the LLVM
The null hypothesis is to not add a project to LLVM. In order to add a
project, it should be justified. What are the justifications here? I've
quoted the snippets above where it is made clear that Google's needs do
*not* line up with the needs of the community. But the proposal failed
to mention what the actual needs of Google are.
So what are they?
The current list of C ABI environments which LLVM recognizes is:
Would this proposed libc be adding a new C ABI environment to this list,
or maintaining API/ABI compatibility with one or more of these?
Finally, I'm only aware of 2 operating systems where the libc is not an
integral part of the system, which is Linux and Windows. For example on
macOS, FreeBSD, OpenBSD, and DragonFlyBSD, the libc is guaranteed to be
available, and must be dynamically linked, because this is the stable
syscall ABI. So it would only make sense for an LLVM libc to be for
Linux and Windows. It seems reasonable to assume that Google is only
interested in Linux. In this case I have to re-iterate my original
question, what are the needs that are not being met by existing Linux
libcs, such as musl?
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 833 bytes
Desc: OpenPGP digital signature
More information about the llvm-dev