<div dir="ltr"><div dir="ltr">On Thu, Jun 27, 2019 at 5:04 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"><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></blockquote><div><br></div><div>Yes, design points are important.  However, I think understanding what it is which is being built is equally important.  Without understanding what exactly the capabilities are, you can design something which doesn’t meet any of the requirements.</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 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></blockquote><div><br></div><div>I actually am interested in this - it would enable something like a complete dynamically linked libc which can be used on embedded environments.  I imagine that an excellent way to slice the library would be along the subsections of Section 7 of the C11 specification (e.g. stdio, localization, mathematics, etc).<br></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 dir="ltr"><br></div><div dir="ltr">Getting that right would also make compiler_rt a bit nicer.</div></div></blockquote><div><br></div><div>I am afraid I really don’t understand this part.  Could you please explain how this would improve compiler-rt?  I suspect my understanding is incorrect on something as compiler-rt is really three things:</div><div><br></div><div>- the sanitizers (which can be split into their own repository/directory/etc)</div><div>- a collection of odds and ends (e.g. the fuschia C runtime support)<br>- the builtins (which are extracted functions for performing common operations which the CPU may not support or can become expensive to inline everywhere or be unweildy to implement inline in the compiler)<br><br>Which bit would be influenced by the design decisions for a 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 dir="ltr"></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="gmail-m_3641354812616288687AppleMailSignature" 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" target="_blank">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" target="_blank">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_3641354812616288687gmail-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_3641354812616288687gmail-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_3641354812616288687gmail-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_3641354812616288687gmail-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_3641354812616288687gmail-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-m_3641354812616288687gmail_signature">Saleem Abdulrasool<br>compnerd (at) compnerd (dot) org</div></div>
</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>