Bug#624354: Processed: Re: Bug#624354: ./xpcshell: error while loading shared libraries: ./libxul.so: R_PPC_REL24 relocation at 0x0f9f0148 for symbol `_restgpr_29_x' out of range
- To: Michel Dänzer <firstname.lastname@example.org>
- Cc: Gabriel Paubert <email@example.com>, Matthias Klose <firstname.lastname@example.org>, email@example.com, Cyril Brulebois <firstname.lastname@example.org>, email@example.com
- Subject: Bug#624354: Processed: Re: Bug#624354: ./xpcshell: error while loading shared libraries: ./libxul.so: R_PPC_REL24 relocation at 0x0f9f0148 for symbol `_restgpr_29_x' out of range
- From: Mike Hommey <firstname.lastname@example.org>
- Date: Wed, 31 Aug 2011 06:35:09 +0200
- Message-id: <20110831043509.GC3643@glandium.org>
- Reply-to: Mike Hommey <email@example.com>, firstname.lastname@example.org
- In-reply-to: <email@example.com>
- References: <20110428093216.GB7806@glandium.org> <20110428094048.GA8307@glandium.org> <20110428095518.GA8610@glandium.org> <firstname.lastname@example.org> <20110428100442.GA9729@glandium.org> <20110428101054.GA9846@glandium.org> <20110428121715.GA5336@iram.es> <20110430100041.GB24036@glandium.org> <20110430180457.GA9928@glandium.org> <email@example.com>
On Mon, Aug 29, 2011 at 06:48:49PM +0200, Michel Dänzer wrote:
> Fast forward four months...
> On Sam, 2011-04-30 at 20:04 +0200, Mike Hommey wrote:
> > On Sat, Apr 30, 2011 at 12:00:41PM +0200, Mike Hommey wrote:
> > > On Thu, Apr 28, 2011 at 02:17:15PM +0200, Gabriel Paubert wrote:
> > > > On Thu, Apr 28, 2011 at 12:10:54PM +0200, Mike Hommey wrote:
> > > > > On Thu, Apr 28, 2011 at 12:04:42PM +0200, Mike Hommey wrote:
> > > > > > Let me write it again:
> > > > > > - The R_PPC_REL24 relocations are all over libxul.so on objects that are
> > > > > > built -fPIC.
> > > > > > - libcrmf.a is also linked into libxul.so, and it also contains
> > > > > > R_PPC_REL24 relocations, but all the objects it contains are built
> > > > > > -fPIC.
> > > > >
> > > > > And this is a -Os bug, apparently. Building with -O2 doesn't seem to
> > > > > yield these relocations.
> > > >
> > > > That's because the out-of-line prologue/epilogue register save and
> > > > restore functions are only used at -Os (they save size).
> > > >
> > > > Now I believe, but don't quote me on that, that the linker
> > > > should insert a copy of these functions in every shared library
> > > > since these functions have non standard linkage and probably
> > > > would not survive crossing shared library boundaries.
> > > >
> > > > I can see a bug if the shared library text size is above
> > > > 32M or so (needs several copies of these functions), but
> > > > I don't think the libraries are that big.
> > >
> > > The linker actually normally does that, because it compiles with -lgcc,
> > > which will link libgcc.a, which contains these functions.
> > >
> > > However, for some reason, in libxul.so case, gcc uses -shared-libgcc,
> > > which I fail to see where it collects it from (thanks KiBi for the
> > > verbose build, see below).
> > >
> > > OTOH, I still can't reproduce with a simple test case. The linker still
> > > seems to do the right thing. Even if I use the same build flags.
> > > I really don't know what makes the libxul.so case so special. Its size?
> > So, the problem is its compile line, containing
> > -lstartup-notification-1, and has nothing to do with -shared-libgcc.
> > It looks like startup-notification was built with a broken toolchain in
> > 2009 (will ask for a binNMU), and exported the _rest* symbols that
> > libgcc.a also contains. As -lstartup-notification-1 appears before -lgcc
> > on the link line, ld wrongly picks the versions in
> > startup-notification-1.
> > So it looks to me like there were and are several problems:
> > - The original problem that made startup-notification export these
> > symbols, that is gone.
> > - gcc, that doesn't mark _rest* symbols as hidden in object files (they
> > are in libgcc.a)
> > I guess fixing the latter would either force ld to use the libgcc.a
> > symbols or fail to link with the startup-notification symbols.
> /usr/lib/xulrunner-6.0/libxul.so still has lots of these R_PPC_REL24
> relocations, and today this prevented iceweasel from starting at all for
> me, as one of them ended up unresolvable.
> AFAICT the libstartup-notification0 problem should be fixed now. Is this
> just a gcc -Os / binutils bug that should be worked around at least for
> now by building with -O2? I'm successfully running iceweasel with
> libxul.so rebuilt with -O2, it's 100% R_PPC_REL24 free.
> (I wonder if it's worth trying to use -Os at all, given all the trouble
> it's caused; AFAIK it's also known to result in generally rather bad
> code generation...)
Interestingly, according to bug #639851, 6.0-2 didn't have the problem.
Which suggests something else broke.