From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/776 Path: news.gmane.org!not-for-mail From: Rich Felker Newsgroups: gmane.linux.lib.musl.general Subject: Re: musl 0.8.10 released Date: Wed, 25 Apr 2012 22:51:14 -0400 Message-ID: <20120426025114.GU14673@brightrain.aerifal.cx> References: <20120425184917.GT14673@brightrain.aerifal.cx> <20120425182245.f5bc8c43.idunham@lavabit.com> Reply-To: musl@lists.openwall.com NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: dough.gmane.org 1335408499 26137 80.91.229.3 (26 Apr 2012 02:48:19 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Thu, 26 Apr 2012 02:48:19 +0000 (UTC) To: musl@lists.openwall.com Original-X-From: musl-return-777-gllmg-musl=m.gmane.org@lists.openwall.com Thu Apr 26 04:48:18 2012 Return-path: Envelope-to: gllmg-musl@plane.gmane.org Original-Received: from mother.openwall.net ([195.42.179.200]) by plane.gmane.org with smtp (Exim 4.69) (envelope-from ) id 1SNEkk-0002OC-BA for gllmg-musl@plane.gmane.org; Thu, 26 Apr 2012 04:48:18 +0200 Original-Received: (qmail 9444 invoked by uid 550); 26 Apr 2012 02:48:17 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: Original-Received: (qmail 9436 invoked from network); 26 Apr 2012 02:48:17 -0000 Content-Disposition: inline In-Reply-To: <20120425182245.f5bc8c43.idunham@lavabit.com> User-Agent: Mutt/1.5.21 (2010-09-15) Xref: news.gmane.org gmane.linux.lib.musl.general:776 Archived-At: On Wed, Apr 25, 2012 at 06:22:45PM -0700, Isaac Dunham wrote: > On Wed, 25 Apr 2012 14:49:17 -0400 > Rich Felker 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