<div dir="ltr">Some natural questions:<br><br>1) Will libm be included?<br>2) How will llvm libc be different from musl in design perspectives?<br> musl is another widely used libc implementation, available on many Linux distributions (<a href="https://wiki.musl-libc.org/projects-using-musl.html#Linux-distributions-using-musl">https://wiki.musl-libc.org/projects-using-musl.html#Linux-distributions-using-musl</a> and even on Windows! <a href="https://midipix.org/">https://midipix.org/</a>), often used by prebuilt packages because of its lightweightness.<br><br>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.<br><br>> Similar to Clang and libc++, it does seem inevitable that we will need to provide some level of compatibility with other vendors' extensions.<br><br>I'm glad to see this. Many uses of glibc symbol versioning are actually "bug-compatibility".<br>It'd be good to push applications to fix their own problems.<br><br>> Implement dynamic loading and linking support.<br><br>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.<br>Entirely forgetting it may bring trouble when it is eventually decided to be implemented in the future.<br><br>> Support for more architectures (we'll start with just x86-64 for simplicity).<br><br>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..<br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, Jun 25, 2019 at 8:41 AM Zachary Turner via llvm-dev <<a href="mailto:llvm-dev@lists.llvm.org">llvm-dev@lists.llvm.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div><div dir="auto">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.</div></div><div dir="auto"><br></div><div dir="auto">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?</div><div dir="auto"><br></div><div dir="auto">Have you considered just starting with a blank slate?</div><div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, Jun 24, 2019 at 5:33 PM Chris Lattner via llvm-dev <<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div style="overflow-wrap: break-word;"><disclaimer: I work at Google, though not on anything related to this project><div><br></div><div><div><blockquote type="cite"><div>On Jun 24, 2019, at 3:23 PM, Siva Chandra via llvm-dev <<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a>> wrote:</div><div><div dir="ltr"><span id="gmail-m_-4305794529521583729m_634122694686579039gmail-docs-internal-guid-31026820-7fff-9c8b-7125-459f728330fd"><br><div style="line-height:1.38;margin-top:0pt;margin-bottom:0pt"><span style="font-family:Arial;background-color:transparent;font-variant-numeric:normal;font-variant-east-asian:normal;vertical-align:baseline;white-space:pre-wrap">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:</span></div><br><ol style="margin-top:0pt;margin-bottom:0pt"><li dir="ltr" style="list-style-type:decimal;font-family:Arial;background-color:transparent;font-variant-numeric:normal;font-variant-east-asian:normal;vertical-align:baseline;white-space:pre-wrap"><div style="line-height:1.38;margin-top:0pt;margin-bottom:0pt"><span style="background-color:transparent;font-variant-numeric:normal;font-variant-east-asian:normal;vertical-align:baseline;white-space:pre-wrap">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.</span></div></li></ol></span></div></div></blockquote><div><br></div><div>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.</div><div><br></div><blockquote type="cite"><div><div dir="ltr"><span id="gmail-m_-4305794529521583729m_634122694686579039gmail-docs-internal-guid-31026820-7fff-9c8b-7125-459f728330fd"><div style="line-height:1.38;margin-top:0pt;margin-bottom:0pt"><span style="font-family:Arial;background-color:transparent;font-variant-numeric:normal;font-variant-east-asian:normal;vertical-align:baseline;white-space:pre-wrap">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.</span></div></span></div></div></blockquote><div><br></div><div>Fantastic!</div><br><blockquote type="cite"><div><div dir="ltr"><span id="gmail-m_-4305794529521583729m_634122694686579039gmail-docs-internal-guid-31026820-7fff-9c8b-7125-459f728330fd"><br><div style="line-height:1.38;margin-top:0pt;margin-bottom:0pt"><span style="font-family:Arial;background-color:transparent;font-variant-numeric:normal;font-variant-east-asian:normal;vertical-align:baseline;white-space:pre-wrap">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.</span></div><br><div style="line-height:1.38;margin-top:0pt;margin-bottom:0pt"><span style="font-family:Arial;background-color:transparent;font-variant-numeric:normal;font-variant-east-asian:normal;vertical-align:baseline;white-space:pre-wrap">So, what do you think about incorporating this new libc under the LLVM project?</span></div></span></div></div></blockquote></div><br></div><div>I would love to see this, and I think it would fill a significant missing piece in the LLVM ecosystem.</div></div><div style="overflow-wrap: break-word;"><div><br></div><div>-Chris</div></div>_______________________________________________<br>
LLVM Developers mailing list<br>
<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a><br>
<a href="https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev" rel="noreferrer" target="_blank">https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev</a><br>
</blockquote></div></div>
_______________________________________________<br>
LLVM Developers mailing list<br>
<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a><br>
<a href="https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev" rel="noreferrer" target="_blank">https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev</a><br>
</blockquote></div><br clear="all"><div><br></div>-- <br><div dir="ltr" class="gmail_signature"><div dir="ltr">宋方睿</div></div>