[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: 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



On Thu, Apr 28, 2011 at 12:01:04PM +0200, Michel Dänzer wrote:
> On Don, 2011-04-28 at 11:55 +0200, Mike Hommey wrote: 
> > On Thu, Apr 28, 2011 at 11:40:48AM +0200, Mike Hommey wrote:
> > > On Thu, Apr 28, 2011 at 11:32:16AM +0200, Mike Hommey wrote:
> > > > > And none of the offsets match the end of the relocation address ld.so is
> > > > > talking about.
> > > > > 
> > > > > Now, for something interesting, LD_DEBUG=all says this:
> > > > > binding file ./libxul.so [0] to /usr/lib/libstartup-notification-1.so.0 [0]: normal symbol `_restgpr_29_x'
> > > > > 
> > > > > just before failing, and it (obviously) fails on the first of these
> > > > > relocations.
> > > > 
> > > > Actually, it doesn't fail on the first one.
> > > > libxul.so is loaded at 0x0f007000. The failure is at 0x0f9f0148, which
> > > > makes the relocation for offset 0x009e9148, which makes it the 3963th.
> > > 
> > > (easier to find the relocation when you have the base of the library in
> > > memory, really odd alignment, by the way)
> > > 
> > > All in all, it looks to me like it used to work by mere luck, but
> > > somehow now fails because the lib containing the _restgpr_29_x symbol
> > > is too far, which libgcc_s.so would likely be as well. So using a
> > > R_PPC_REL24 relocation for these undefined symbols looks like a big
> > > stretch.
> > 
> > FWIW, taking a look at where these relocations take place show that the
> > corresponding symbols (from the -dbg package) are in functions coming
> > from objects that *are* built -fPIC.
> > 
> > It also happens that, in libnss3-1d, the libcrmf.a file contains the
> > same kind of relocations, and all the files built in that lib *are*
> > built -fPIC. That would help having a smaller testcase than iceweasel.
> 
> If libcrmf.a ends up being linked into libxul.so, that would be the
> static library I asked about, and the bug.

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.


Reply to: