[Toybox] diff.c

[enh]

On Tue, Aug 30, 2022 at 3:53 AM Rob Landley <rob at landley.net> wrote:

> 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":
>

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_
https://github.com/ARM-software/optimized-routines _and_ hoping that
someone at intel remembers bionic (and everyone else) and doesn't just work
with glibc (say).


> 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...
>

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.


> 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.


that's a surprising stance from the person who likes static binaries more
than anyone else i know :-)

(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.)

fwiw, bionic _already_ gets its arm/arm64 optimized string/memory routines
(and some of its math) from
https://github.com/ARM-software/optimized-routines 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.)


> But as soon as this
> thing provides its own malloc() "there can be only one" and it's Queen and
> lightshows time.
>

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
:-)


> Rob
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.landley.net/pipermail/toybox-landley.net/attachments/20220901/5a008ff8/attachment-0001.htm>