[llvm-dev] A libc in LLVM

Chris Lattner via llvm-dev
Fri, 28 Jun 2019 00:04:41 -0000

Makes sense, but beyond “capabilities” of the eventual result, I think it is
important to focus on *design* points, since they are the things that will shape
the result as the effort goes from nothing to something.

For example, I think that subset-ability is really important, so imo a build
system that allows compiling different confirmations is really important.  This
implies some configuration description, an internal dependence graph, a way to
depend on targets with multiple possible implementations, etc.

Getting that right would also make compiler_rt a bit nicer.

In any case, if there other design points people are interested in, I’m sure
Siva would appreciate knowing about them.

-Chris

>> On Jun 27, 2019, at 5:47 PM, Saleem Abdulrasool <compnerd at
compnerd.org> wrote:
>>
>> 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/e4f7cc3c/attachment.html>