[llvm-dev] A libc in LLVM

[Ori Bernstein via llvm-dev]

On Thu, 27 Jun 2019 15:43:08 -0700
Siva Chandra via llvm-dev <llvm-dev at lists.llvm.org> wrote:

> On Thu, Jun 27, 2019 at 2:05 PM Chris Lattner via llvm-dev
> <llvm-dev at lists.llvm.org> wrote:
> >
> > Saleem, Owen, others on the thread who are concerned about this: it seems
> > that some of the concern is that the project goals are too narrow, and
> > thus the eventual result may not serve the full community well over time.
> 
> May be my email listing our goals is being misinterpreted as being the
> bounding set of goals for the project. So, let me make it clear again:
> The goals I have listed are just our initial set of goals for the
> project. Members of the community are of course free to add their own
> goals to this set, implement them, and make it a "full solution." I
> have also mentioned in some of my earlier emails that we do not intend
> to design out any particular feature or platform. For example, I have
> said that we do not intend to work on dynamic linking/loading at least
> to begin with. This does not mean that the scope of the project is
> curtailed to static linking. The members of the community are free to
> add support for dynamic linking/loading. In fact, if dynamic
> linking/loading support is added in a modular/"as a library" fashion,
> it makes it a win-win situation as we will be able to take it out if
> we do not require it.

The discussion here makes me strongly suspect that this libc will remain a
linux-only implementation.

OpenBSD, and I think most other BSDs, OSX, Solaris, and others consider libc
an integral part of the system, and modify the ABI between the kernel and libc
with varying frequency. How would you want llvm libc to handle, for example,
OpenBSD's 64 bit time_t transition? There will be other situations like it.

I don't think a Linux-only solution should be adopted by LLVM, and I think that
using a non-system libc is something that will cause more pain than it's worth
outside of cases where someone has full platform control.

I wouldn't mind being proven wrong, maybe people will jump in, port it, and
maintain it on multiple platforms. I'd like to see this happen *before* this
libc was put under the LLVM umbrella.

Libcs can be written outside of LLVM, and code can be imported after it's
in wider use.

But then again, I'm mostly an observer.

-- 
Ori Bernstein <ori at eigenstate.org>