[llvm-dev] A libc in LLVM

[Andrew Kelley via llvm-dev]

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
>     simplicity).
> So, what do you think about incorporating this new libc under the LLVM
> project?
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:

  none
  gnu
  gnuabin32
  gnuabi64
  gnueabi
  gnueabihf
  gnux32
  code16
  eabi
  eabihf
  android
  musl
  musleabi
  musleabihf
  msvc
  itanium
  cygnus
  coreclr
  simulator

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?

Regards,
Andrew

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20190626/5a7a9513/attachment.sig>