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.

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

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.

Show replies

Replying to

I don't think

would be opposed to having support for production runtime support for CFI, ShadowCallStack (arm only), SafeStack, memory tagging, linking in a different malloc at compile-time (so they can use jemalloc or Scudo) or some of the hardening bits they want.

Replying to

Of course, they'd have to write it in C following the code style and spirit of musl rather than implementing it in Google C++ and taking shortcuts based on not needing portable beyond their own platforms. Not sure how likely it is they'd have any interest in trying to do that.