Date: Wed, 25 Apr 2012 22:51:14 -0400 From: Rich Felker <dalias@...ifal.cx> To: musl@...ts.openwall.com Subject: Re: musl 0.8.10 released On Wed, Apr 25, 2012 at 06:22:45PM -0700, Isaac Dunham wrote: > On Wed, 25 Apr 2012 14:49:17 -0400 > Rich Felker <dalias@...ifal.cx> wrote: > > > Hi all, > > > > Since there've been a lot of changes since 0.8.9, many of them fixes > > for annoying bugs, I've made another release in the 0.8 series: > > > > Character classification functions updated to Unicode 6.1 and > > greatly improved. Over/underflow detection and bugs fixed in > > strtod/scanf float support. Minimal stack protector support. Better > > debugging support for shared libraries. Recent breakage in iconv and > > sysconf fixed. Improved musl-gcc wrapper script. > > Seems to work fine from Debian (so far...). > One nit, though: Is there a way to install with PREFIX=/usr, but > libc.so actually residing in /lib instead of symlinked to > /usr/lib/libc.so? I seem to recall doing that once but having some issue with the build system when I did it. I'd like to switch it back too, so I'll look into it again. > Also, does PIC (shared libraries) really have to forcibly enable -O3 ? No, it's just that gcc generates pathologically bad code when it can't inline, and tends to make the code both bigger and slower. In principle, functions that are static and whose address is never taken should be able to assume the GOT register was already set by the caller, and avoid the overhead of setting it again. In practice, every single function goes to the trouble of setting the GOT register, which is really expensive (in size and time). Enabling inlining (which, BTW, is the only difference between -O2 and -O3) fixes the issue mostly. Perhaps it would make sense to just make -O3 the default for everything, and allow it to be easily overridden in config.mak.. Or, I could take it out of PIC and put it in a separate CFLAGS_SHARED variable to make it easy to override. I'm open to suggestions. > This has historically meant "switch on all optimizations, even the > broken ones". If I wanted -O3, I'd specify it myself. No, that's -Ofast. It's possible that at some point in the past, -O3 switched on optimizations that were still buggy, but it's much more likely that the code being compiled was just buggy (violating aliasing rules, etc.) and -O3 exposed the bugs. Since gcc 3.4 (and maybe earlier) there's been no good reason not to use -O3 except optimizing for minimal size (and -Os and -O1 fail to optimize the size of the most important code when -fPIC is used, for the reasons explained above). > On a semi-related note--would -fno-delete-null-pointer-checks be > adviseable? I know there was a security issue in the kernel some > time back, for which this was the solution. I don't see how it would be helpful. The optimization is correct; if a null pointer was dereferenced, the program will already have raised SIGSEGV and entered the signal handler, so there's no way the subsequent if (ptr!=NULL) check will ever be reached. IMO the kernel issue has to do with kernels that allow you to mmap at address 0, in which case dereferencing will not fault. This is rather dangerous, and a properly configured kernel will not allow it. BTW perhaps compiling with and without that option and comparing the generated code would help find bugs...but I suspect the same can be achieved more easily with clang's static analysis. > Somehow I suspect that sysvinit won't compile, for the same reasons > as previously (missing macros, strdupa, char **environ, ut_addr, > [UW]TMP_FILE aliases for _[UW]TMP_PATH--all missing despite > _GNU_SOURCE being defined). I'd be happy to work on fixing it. By the way, strdupa is just -D"strdupa(x)=strcpy(alloca(strlen(x)+1),x)" Rich
Powered by blists - more mailing lists
Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.