On 8/29/22 19:17, enh wrote: > On Sat, Aug 27, 2022 at 1:59 AM Rob Landley <[email protected] > <mailto:[email protected]>> 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 _______________________________________________ Toybox mailing list [email protected] http://lists.landley.net/listinfo.cgi/toybox-landley.net
