[Toybox] diff.c

[Rob Landley]

On 8/29/22 19:17, enh wrote:
> On Sat, Aug 27, 2022 at 1:59 AM Rob Landley <rob at landley.net
> <mailto:rob at landley.net>> wrote:
> 
>     On 8/26/22 18:11, enh via Toybox wrote:
>     > have you tried? the llvm-libc folks are effectively starting from scratch
>     > (https://github.com/llvm/llvm-project/blob/main/libc/src/stdlib/qsort.cpp, and
>
>     Sigh. I had honestly hoped that particular https://xkcd.com/927/ had died during
>     the pandemic, or at least quiesced like klibc and newlib. Last I'd heard it
>     mentioned was
>     https://hub.packtpub.com/google-proposes-a-libc-in-llvm-rich-felker-of-musl-libc-thinks-its-a-very-bad-idea/
> 
> i think you're thinking of the wrong axis here. i think far more interesting
> than OS is cpu architecture. right now there's no one place everyone can pull
> from that has optimized code for arm/x86/etc. even getting the different parts
> of arm or intel to coordinate can be hard ("oh, yeah, we own math libraries, but
> only for the _server_" --- not throwing any stones; i work for a company with
> 100k employees too, and that's just the way large organizations end up). llvm is
> one of the few pieces of common ground (and it's not GPL, so it doesn't have the
> "oh, shit, we worked on glibc but didn't realize you couldn't take code from
> there" problem).
> 
> so for string/memory, math, etc, i actually think it's a good idea. (i reserve
> the right to change my mind when they want to break "memcpy == memmove", say,
> but that's fine --- they're not making me take any code i don't actually want.
> and i won't be able to take any code that involves ABI anyway, since i can't
> change ABI.)
> 
> hell, even if it just gives the three(+) BSDs a common source to share from,
> that would be a step in the right direction!

I defer to Rich Felker and Jeff Dionne on this one. I trust their domain
expertise (Jeff knows hardware and Rich cares far more about IEEE floating point
compatibility details than I'm likely to ever understand). If either of them
thinks this sounds like a good idea. then I accept being wrong here.

But a significant problem I've personally had is that llvm's version of libgcc.a
is messy to the point of being almost uncompilable. (You may remember the thread
from a year ago starting at
http://lists.landley.net/pipermail/toybox-landley.net/2021-August/020537.html .)
If they haven't managed a reasonable libcc yet, how are they going to do a good
job with libc?

And logically the assembly optimized stuff would be more libcc.a than libc.a,
because the things that really need polishing wind up inlined by the compiler
anyway as "builtins":

https://gcc.gnu.org/onlinedocs/gcc/Other-Builtins.html

So it's conceivable libcc could eat libm (as the above builtins basically
already have), but a quick glance at posix shows libc is full of stuff like
getservent(), getpeername(), globfree(), gmtime_r()... Signing up to produce an
OS-portable version of psiginfo() or defining what should and should not be
included in a given regcomp/regexec implementation seems a VERY different
mandate than "here's the most optimal strcmp() for tiger lake". And then you
either choose to have your new libc NOT to go beyond that into man 2 unshare
(missing functionality), or have linux vs bsd incompatiblity, or resolve that
incompatibility yourself...

What you want them to do doesn't sound to me like what they're trying to do. An
LD_PRELOAD that goes before libc.so to provide optimized stuff might be
interesting, and having libcc provide that semidigested AST format for LTO
inlines so your builtins list is dynamic would be novel. But as soon as this
thing provides its own malloc() "there can be only one" and it's Queen and
lightshows time.

Rob