[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Thu, 15 May 2014 00:45:51 -0400
From: Rich Felker <dalias@...c.org>
To: Thomas Petazzoni <thomas.petazzoni@...e-electrons.com>
Cc: musl@...ts.openwall.com
Subject: Re: Broken GCC versions: 4.8.2 and 4.9.0
On Sun, May 11, 2014 at 12:19:43PM -0400, Rich Felker wrote:
> On Sun, May 11, 2014 at 06:10:20PM +0200, Thomas Petazzoni wrote:
> > Dear Rich Felker,
> >
> > On Sat, 10 May 2014 21:05:03 -0400, Rich Felker wrote:
> >
> > > It's come to my attention that GCC versions 4.8.2 and 4.9.0 are
> > > performing invalid optimizations that result in a broken musl
> > > libc.a/libc.so. It's not clear yet whether there's a good workaround,
> > > or whether we should attempt to work around the problem, so for now,
> > > please just be aware that these versions of GCC cannot be used to
> > > compile musl. Using them to compile programs against musl should not
> > > be a problem. I'll post more details later. The short version is that
> > > it's making incorrect assumptions about the reachability of global
> > > variables that have a local weak definition and an external strong
> > > one.
> >
> > Hum, interesting. I've recently tested gcc 4.8.2 + musl on ARM, and gcc
> > 4.9.0 + musl on i386, and I could boot a minimal musl+Busybox system
> > under Qemu perfectly fine. Maybe the problem you refer to only affects
> > certain parts of libc.a/libc.so?
>
> I've filed the bug report which you can see here:
>
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=61144
>
> Something like the following command should confirm whether your build
> is affected:
>
> nm src/stdio/fflush.o | grep stdout
>
> For broken gcc versions, there is no output. For non-broken ones, you
> should see something like:
>
> 00000000 V __stdout_used
>
> Note that fflush(0) is just one place where the behavior may be
> affected by the invalid optimization. There are at least several
> others, though at a glance the others are more likely to be affected
> only with heavy inlining (but in principle, they "should" be affected
> even without inlining as long as inter-procedural optimizations are
> performed).
Attached is a proposed patch to _detect_ this issue (not work around
it) and reject the broken compiler. It does not hard-code an
assumption that certain versions are broken, but tests the behavior
with the seleted CFLAGS to see if the bug is present.
I've considered multiple possible workarounds, but all of them have
drawbacks:
1. Making the dummies non-static. This pollutes the symbol table and
precludes -Wl,--gc-sections from being able to remove them when
building libc.so unless visibility magic is also used.
2. Adding __attribute__((__used__)) to the static dummies. This works,
and it's semantically correct that they should be considered "used"
and not optimized out, but the problem actually isn't gcc optimizing
them out; rather it's correctly keeping them around, but wrongly
constant-folding them in expressions. So it's just "by chance" (a side
effect of the bug) that adding this makes the problem go away. Also,
adding it would require extra macro ugliness to account for the fact
that we don't want to require the compiler to support
__attribute__((__used__)).
3. Automatically adding -fno-toplevel-reorder to CFLAGS to suppress
the optimizations when the bug is detected. This works now, but it's
possible that it might not work for a future buggy gcc version. (It
also produces a less-optimized libc.) Requiring the user to manually
add this option if they want to try using a buggy compiler allows us
to test and make sure the bug actually went away with the option
added.
Hopefully we can get the GCC folks to take this regression seriously
and get it fixed before they release any more broken releases...
Rich
View attachment "detect_gcc_4.9.0_bug.diff" of type "text/plain" (1915 bytes)
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.
