[llvm-dev] A libc in LLVM

[Fāng-ruì Sòng via llvm-dev]

Some natural questions:

1) Will libm be included?
2) How will llvm libc be different from musl in design perspectives?
   musl is another widely used libc implementation, available on many Linux
distributions (
https://wiki.musl-libc.org/projects-using-musl.html#Linux-distributions-using-musl
and even on Windows! https://midipix.org/), often used by prebuilt packages
because of its lightweightness.

It'd be great if the library will be designed with multiple kernels in
mind. That can be a purpose why another libc implementation is needed. :)
Then another natural question is how the kernel differences will be
effectively isolated. The platform specific macros in compiler-rt may be a
bit messy now. I hope we can prevent that situation.

> Similar to Clang and libc++, it does seem inevitable that we will need to
provide some level of compatibility with other vendors' extensions.

I'm glad to see this. Many uses of glibc symbol versioning are actually
"bug-compatibility".
It'd be good to push applications to fix their own problems.

> Implement dynamic loading and linking support.

Lack of support for dynamic linking circumvents many problems: PLT lazy
binding, dlclose, ABI compatibility (newer binary on older loaders), etc.
However, it is good to make the intention clear whether the feature will
ever be implemented in an early stage because it will influence many design
choices of many interfaces.
Entirely forgetting it may bring trouble when it is eventually decided to
be implemented in the future.

> Support for more architectures (we'll start with just x86-64 for
simplicity).

This is fine. musl has 5 or 6 arch-dependent files for each port
(arch/*/*.h) and a few more in the user interface arch/*/bits/*.h . It
proves that a new port does not need a bunch of additional logic. Many
optimized routines may inevitably get added, though..

On Tue, Jun 25, 2019 at 8:41 AM Zachary Turner via llvm-dev <
llvm-dev at lists.llvm.org> wrote:

> I’m not totally sold on the idea of having it be a layer between system
> libc and application.  I think this is likely to create a split between
> windows and non windows that will be difficult to overcome.
>
> It also seems like it brings with it its own set of difficulties.  Where
> can you make a separation in libc such that you’re guaranteed that the two
> pieces do not share any state, especially given that not everyone is going
> to be using the same libc?
>
> Have you considered just starting with a blank slate?
>
> On Mon, Jun 24, 2019 at 5:33 PM Chris Lattner via llvm-dev <
> llvm-dev at lists.llvm.org> wrote:
>
>> <disclaimer: I work at Google, though not on anything related to this
>> project>
>>
>> On Jun 24, 2019, at 3:23 PM, Siva Chandra via llvm-dev <
>> llvm-dev at lists.llvm.org> wrote:
>>
>> We are still in the early stages, but we do have some high-level goals
>> and guiding principles of the initial scope we are interested in pursuing:
>>
>>
>>    1. The project should mesh with the "as a library" philosophy of the
>>    LLVM project: even though "the C Standard Library" is nominally "a
>>    library," most implementations are, in practice, quite monolithic.
>>
>>
>> This is awesome.  I’d really love to see a corpus of functionality built
>> as a set of libraries that can be sliced and remixed in different ways per
>> the needs of different use-cases.
>>
>> For these areas, the community is of course free to contribute. Our hope
>> is that, preserving the "as a library" design philosophy will make such
>> extensions easy, and allow retaining the simplicity when these features
>> aren't needed.
>>
>>
>> Fantastic!
>>
>>
>> We intend to build the new libc in a gradual manner. To begin with,  the
>> new libc will be a layer sitting between the application and the system
>> libc. Eventually, when the implementation is sufficiently complete, it will
>> be able to replace the system libc at least for some use cases and contexts.
>>
>> So, what do you think about incorporating this new libc under the LLVM
>> project?
>>
>>
>> I would love to see this, and I think it would fill a significant missing
>> piece in the LLVM ecosystem.
>>
>> -Chris
>> _______________________________________________
>> LLVM Developers mailing list
>> llvm-dev at lists.llvm.org
>> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>>
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>


-- 
宋方睿
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20190625/e56501ae/attachment-0001.html>