[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
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.
