Conversation

🤔

an I wonder: would the LLVM libc be written in C++? Also, what would you call it? llibc? Logical next step is to have an LLVM kernel. What would you call that kernel? It would certainly be low-level, and would handle virtual machines (as well as virtual memory).

Quote Tweet

LLVM Weekly

@llvmweekly

Jun 25, 2019

Is it time for an LLVM libc? The Google LLVM team are collecting feedback lists.llvm.org/pipermail/llvm

Replying to

There could be so many more interesting LLVM projects to solve problems with existing platforms! - LLDE - the LLVM Desktop Environment - ALLSA - the Advanced LLVM Sound Architecture

Replying to

and

LLVM/Linux

Replying to

and

WSLL

Replying to

and

I wish I could take this as light-heartedly as yousall do, but Google already has its own libc, Bionic, and it's the crappiest of the crap software you can imagine calling itself a libc. They should work on perhaps improving that instead of polluting the space with one more.

Replying to

I totally agree it's ridiculous, especially when musl already exists and seems like it serves all their stated needs?

Replying to

I think they primarily care about Fuchsia support, where they use a fork of musl ported over to Fuchsia and with some added features. I think the chance is pretty low of musl supporting Fuschsia upstream, but they could probably land a fair bit of what they need upstream.

Replying to

The original proposal is x86-64 first, and a subsequent response asks for ARM64 support for Fuchsia, so I don't think the main driver it Fuchsia (and if it were, it wouldn't be signed "The Google LLVM Contributors").

Replying to

I doubt it has anything to do with Android though. I'm not sure why they would want it if not for Fuchsia support. There are a lot of things they use that aren't in musl right now but other than Fuchsia support I think most of it would be welcome there, even if a bit reluctantly.

Replying to

Google has quite a few x86-64 machines, running security-critical software. I'm guessing that's the main driver for this proposal 🙂

Replying to

I have a good idea of what's missing from musl for their needs though, and it doesn't make any sense for them to make a whole new libc if it's only for Linux. Having it in LLVM also implies needing to deal with more portability, including deciding how to approach Windows support.

9:58 PM · Jun 25, 2019Twitter Web Client

Replying to

I could see people wanting a libc portable across *BSD, Linux, maybe even Windows, etc. I can't understand why Google would want to deal with maintaining that, so that's why I assumed it was compelled by their current fork of musl in Fuchsia. I'm not understanding the reasoning.

Replying to

FWIW, while it'll be super cool if Fuchsia (or others) can use this, that's not the motivation. And the team looked at musl (and others) and none seemed to be the right trade off from an engineering POV. (It's possible they're wrong of course, but they are considering them.)

Show replies