<html><head><meta http-equiv="content-type" content="text/html; charset=utf-8"></head><body dir="auto"><div dir="ltr"><span></span></div><div dir="ltr">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.</div><div dir="ltr"><br></div><div dir="ltr">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.</div><div dir="ltr"><br></div><div dir="ltr">Getting that right would also make compiler_rt a bit nicer.</div><div dir="ltr"><br></div><div dir="ltr">In any case, if there other design points people are interested in, I’m sure Siva would appreciate knowing about them.</div><div dir="ltr"><br><div id="AppleMailSignature" dir="ltr"><div>-Chris</div></div><div dir="ltr"><br>On Jun 27, 2019, at 5:47 PM, Saleem Abdulrasool <<a href="mailto:compnerd@compnerd.org">compnerd@compnerd.org</a>> wrote:<br><br></div><blockquote type="cite"><div dir="ltr"><div dir="ltr"><div dir="ltr">On Thu, Jun 27, 2019 at 2:05 PM Chris Lattner <<a href="mailto:clattner@nondot.org">clattner@nondot.org</a>> wrote:<br></div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="auto">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.<div><br></div><div>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.<br></div></div></blockquote><div><br></div><div>Sure, I think that would be a good idea. Off the top of my head, something like this would be a good starting point:<br><br>- a complete C11 standards compliant library (with complete support for dynamic linking - remember __declspec(dllimport))<br>- bundled dynamic loader which is capable of loading ELF/PE/MachO binaries</div><div>- full TLS compatibility (including copy relocation)<br>- compatible with OSes supported by LLVM (at least Windows, FreeBSD, Darwin, and Linux)<br>- compatible with popular architectures supported by LLVM (at least x86, arm, arm64, and PPC)<br>- portable code (e.g. no weak symbols)<br>- ability to externalise (and even exclude!) locale data<br>- optional POSIX layer<br>- optional inclusion of C11 annexes<br>- complete enough to replace the default system libc</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="auto"><div><div id="gmail-m_5323728225600394761AppleMailSignature" dir="ltr"><div>-Chris</div></div><div dir="ltr"><br>On Jun 27, 2019, at 1:19 PM, Owen Anderson via llvm-dev <<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a>> wrote:<br><br></div><blockquote type="cite"><div dir="ltr"><br><div><br><blockquote type="cite"><div>On Jun 27, 2019, at 2:53 PM, Saleem Abdulrasool via llvm-dev <<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a>> wrote:</div><br class="gmail-m_5323728225600394761Apple-interchange-newline"><div><blockquote class="gmail_quote" style="font-family:Helvetica;font-size:12px;font-style:normal;font-variant-caps:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;text-decoration:none;margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><span id="gmail-m_5323728225600394761gmail-m_-6752588611450016043gmail-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"><br class="gmail-m_5323728225600394761Apple-interchange-newline">So, what do you think about incorporating this new libc under the LLVM project?</span></div></span></div></blockquote><div style="font-family:Helvetica;font-size:12px;font-style:normal;font-variant-caps:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;text-decoration:none"><br></div><div style="font-family:Helvetica;font-size:12px;font-style:normal;font-variant-caps:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;text-decoration:none">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.</div><br class="gmail-m_5323728225600394761Apple-interchange-newline"></div></blockquote></div><br><div>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.</div><div><br></div><div>To turn the question around, why should *this* libc (assuming it will be built whether or not LLVM accepts it) be *the* LLVM libc?</div><div><br></div><div>--Owen</div></div></blockquote><blockquote type="cite"><div dir="ltr"><span>_______________________________________________</span><br><span>LLVM Developers mailing list</span><br><span><a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a></span><br><span><a href="https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev" target="_blank">https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev</a></span><br></div></blockquote></div></div></blockquote></div><br clear="all"><div><br></div>-- <br><div dir="ltr" class="gmail_signature">Saleem Abdulrasool<br>compnerd (at) compnerd (dot) org</div></div>
</div></blockquote></div></body></html>