<div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, Aug 30, 2022 at 3:53 AM Rob Landley <<a href="mailto:rob@landley.net">rob@landley.net</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">On 8/29/22 19:17, enh wrote:<br>
> On Sat, Aug 27, 2022 at 1:59 AM Rob Landley <<a href="mailto:rob@landley.net" target="_blank">rob@landley.net</a><br>
> <mailto:<a href="mailto:rob@landley.net" target="_blank">rob@landley.net</a>>> wrote:<br>
> <br>
>     On 8/26/22 18:11, enh via Toybox wrote:<br>
>     > have you tried? the llvm-libc folks are effectively starting from scratch<br>
>     > (<a href="https://github.com/llvm/llvm-project/blob/main/libc/src/stdlib/qsort.cpp" rel="noreferrer" target="_blank">https://github.com/llvm/llvm-project/blob/main/libc/src/stdlib/qsort.cpp</a>, and<br>
><br>
>     Sigh. I had honestly hoped that particular <a href="https://xkcd.com/927/" rel="noreferrer" target="_blank">https://xkcd.com/927/</a> had died during<br>
>     the pandemic, or at least quiesced like klibc and newlib. Last I'd heard it<br>
>     mentioned was<br>
>     <a href="https://hub.packtpub.com/google-proposes-a-libc-in-llvm-rich-felker-of-musl-libc-thinks-its-a-very-bad-idea/" rel="noreferrer" target="_blank">https://hub.packtpub.com/google-proposes-a-libc-in-llvm-rich-felker-of-musl-libc-thinks-its-a-very-bad-idea/</a><br>
> <br>
> i think you're thinking of the wrong axis here. i think far more interesting<br>
> than OS is cpu architecture. right now there's no one place everyone can pull<br>
> from that has optimized code for arm/x86/etc. even getting the different parts<br>
> of arm or intel to coordinate can be hard ("oh, yeah, we own math libraries, but<br>
> only for the _server_" --- not throwing any stones; i work for a company with<br>
> 100k employees too, and that's just the way large organizations end up). llvm is<br>
> one of the few pieces of common ground (and it's not GPL, so it doesn't have the<br>
> "oh, shit, we worked on glibc but didn't realize you couldn't take code from<br>
> there" problem).<br>
> <br>
> so for string/memory, math, etc, i actually think it's a good idea. (i reserve<br>
> the right to change my mind when they want to break "memcpy == memmove", say,<br>
> but that's fine --- they're not making me take any code i don't actually want.<br>
> and i won't be able to take any code that involves ABI anyway, since i can't<br>
> change ABI.)<br>
> <br>
> hell, even if it just gives the three(+) BSDs a common source to share from,<br>
> that would be a step in the right direction!<br>
<br>
I defer to Rich Felker and Jeff Dionne on this one. I trust their domain<br>
expertise (Jeff knows hardware and Rich cares far more about IEEE floating point<br>
compatibility details than I'm likely to ever understand). If either of them<br>
thinks this sounds like a good idea. then I accept being wrong here.<br>
<br>
But a significant problem I've personally had is that llvm's version of libgcc.a<br>
is messy to the point of being almost uncompilable. (You may remember the thread<br>
from a year ago starting at<br>
<a href="http://lists.landley.net/pipermail/toybox-landley.net/2021-August/020537.html" rel="noreferrer" target="_blank">http://lists.landley.net/pipermail/toybox-landley.net/2021-August/020537.html</a> .)<br>
If they haven't managed a reasonable libcc yet, how are they going to do a good<br>
job with libc?<br>
<br>
And logically the assembly optimized stuff would be more libcc.a than libc.a,<br>
because the things that really need polishing wind up inlined by the compiler<br>
anyway as "builtins":<br></blockquote><div><br></div><div>i actually think this is one of the stronger arguments for llvm-libc --- bionic already outsources all libm functions that _have_ a builtin (by having a one-liner that inlines the builtin) to ensure consistency here. and i'd rather have arm/intel contributing to llvm in a way that can potentially be inlined as a builtin than have to keep updating llvm _and_ <a href="https://github.com/ARM-software/optimized-routines">https://github.com/ARM-software/optimized-routines</a> _and_ hoping that someone at intel remembers bionic (and everyone else) and doesn't just work with glibc (say).</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">
<a href="https://gcc.gnu.org/onlinedocs/gcc/Other-Builtins.html" rel="noreferrer" target="_blank">https://gcc.gnu.org/onlinedocs/gcc/Other-Builtins.html</a><br>
<br>
So it's conceivable libcc could eat libm (as the above builtins basically<br>
already have), but a quick glance at posix shows libc is full of stuff like<br>
getservent(), getpeername(), globfree(), gmtime_r()... Signing up to produce an<br>
OS-portable version of psiginfo() or defining what should and should not be<br>
included in a given regcomp/regexec implementation seems a VERY different<br>
mandate than "here's the most optimal strcmp() for tiger lake". And then you<br>
either choose to have your new libc NOT to go beyond that into man 2 unshare<br>
(missing functionality), or have linux vs bsd incompatiblity, or resolve that<br>
incompatibility yourself...<br></blockquote><div><br></div><div>yeah, i don't know what their plans are there, and anything with ABI is inherently uninteresting to me because i'm already stuck with a historic "mostly BSD-ish" ABI.</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">
What you want them to do doesn't sound to me like what they're trying to do. An<br>
LD_PRELOAD that goes before libc.so to provide optimized stuff might be<br>
interesting, and having libcc provide that semidigested AST format for LTO<br>
inlines so your builtins list is dynamic would be novel.</blockquote><div><br></div><div>that's a surprising stance from the person who likes static binaries more than anyone else i know :-)</div><div><br></div><div>(i know glibc has gone the LD_PRELOAD kind of route for this stuff, but bionic's gone with ifuncs. that seems like the best trade-off for us. there are reasons why SoC vendors might want to be able to substitute their own routines, but -- having been there before back in the arm32 days where everyone was shipping their own string/memory routines -- that was a disaster for correctness and compatibility. _i_ wouldn't want to go down that path again, and i suspect app developers wouldn't either. even though CTS has a lot more tests now, it's inherently easier to catch regressions than it is to catch novel ways to break things.)</div><div><br></div><div>fwiw, bionic _already_ gets its arm/arm64 optimized string/memory routines (and some of its math) from <a href="https://github.com/ARM-software/optimized-routines">https://github.com/ARM-software/optimized-routines</a> so there's a lot of precedent here. (for bionic, at least. like i said, each the bsds struggles to stay in sync with the other two bsds; in my experience there can be more divergence between bsds than there is between macos and freebsd, which is its major upstream.)</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">But as soon as this<br>
thing provides its own malloc() "there can be only one" and it's Queen and<br>
lightshows time.<br></blockquote><div><br></div><div>not unless you build and ship _their_ malloc. by that argument bionic can't use as much open/net/free-bsd code as it does, which is demonstrably false :-)</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">
Rob<br>
</blockquote></div></div>