[llvm-dev] A libc in LLVM

[Saleem Abdulrasool via llvm-dev]

On Thu, Jun 27, 2019 at 2:05 PM Chris Lattner <clattner at nondot.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.
>
> Would any of you be interested in what we should consider as the list of
> requirements for such a full solution?  It would make it much easier to
> evaluate initial steps if we were to have a big picture of the problem to
> solve over time.
>

Sure, I think that would be a good idea.  Off the top of my head, something
like this would be a good starting point:

- a complete C11 standards compliant library (with complete support for
dynamic linking - remember __declspec(dllimport))
- bundled dynamic loader which is capable of loading ELF/PE/MachO binaries
- full TLS compatibility (including copy relocation)
- compatible with OSes supported by LLVM (at least Windows, FreeBSD,
Darwin, and Linux)
- compatible with popular architectures supported by LLVM (at least x86,
arm, arm64, and PPC)
- portable code (e.g. no weak symbols)
- ability to externalise (and even exclude!) locale data
- optional POSIX layer
- optional inclusion of C11 annexes
- complete enough to replace the default system libc


> -Chris
>
> On Jun 27, 2019, at 1:19 PM, Owen Anderson via llvm-dev <
> llvm-dev at lists.llvm.org> wrote:
>
>
>
> On Jun 27, 2019, at 2:53 PM, Saleem Abdulrasool via llvm-dev <
> llvm-dev at lists.llvm.org> wrote:
>
>
>> So, what do you think about incorporating this new libc under the LLVM
>> project?
>>
>
> As stated, I really feel that this is far too specialised to certain use
> cases that are pertinent to Google.  I think that this needs to be
> broadened to allow a general purpose libc much as libc++ is a general C++
> implementation.  I think that the project has a different set of
> requirements and seems like it would be extremely interesting to see how it
> would develop over time.  This could really be an interesting choice for a
> certain type of project but as described feels like it is best explored
> outside of the umbrella of LLVM.
>
>
> I don't have a strong stake in this decision, but Saleem's commentary
> matches my thoughts on the topic.  Maybe some of this is related to
> messaging - would the proposed project be *an* LLVM libc or *the* LLVM
> libc.  There is already at least one instance within the LLVM umbrella
> where a subproject designed and built to a particular set of constraints
> became *the* LLVM solution, and ended up disincentivizing investment from
> contributors whose priorities didn't match those constraints.  Staking the
> blessed-by-LLVM slot for a piece of the toolchain is not free.
>
> To turn the question around, why should *this* libc (assuming it will be
> built whether or not LLVM accepts it) be *the* LLVM libc?
>
> --Owen
>
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>
>

-- 
Saleem Abdulrasool
compnerd (at) compnerd (dot) org
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20190627/d7549470/attachment.html>