Re: RFH/RFC: ld generating incorrect Elf DT_RELSZ...

[David Daney <ddaney at avtrex dot com>]

Thanks Daniel,

Daniel Jacobowitz wrote:
> On Fri, May 20, 2005 at 01:37:23PM -0700, David Daney wrote:
>
> > I am running a binutils-2.16 / gcc-4.0.0 cross toolchain with 
> > --target=mipsel-linux --host=i686-pc-linux-gnu.
> >
> > It looks to me like ld is generating DT_RELSZ with the wrong value (too 
> > small).  This causes ld.so to not fully relocate the object resulting in 
> > runtime errors.
> >
> > The object in question is libgcj.so.6.0.0 which is the java runtime 
> > library from gcc-4.0.0.
>
>
> It sounds like we've botched the offsets somehow.
>
>
> > From this I calculate that ld.so will do 2661784/8 == 332723 
> > (RELSZ/RELENT) relocations.
> >
> > $ mipsel-linux-readelf -W -r libgcj.so.6 | more
> >
> > Relocation section '.rel.dyn' at offset 0x32ee08 contains 361731 entries:
> > Offset     Info    Type                Sym. Value  Symbol's Name
> > 00000000  00000000 R_MIPS_NONE
> > .
> > .
> > .
> >
> > .rel.dyn contains 361731 relocations.
>
>
> The size of .rel.dyn is rarely all that relevant.  That it starts with
> R_MIPS_NONE is very odd, though.

It always (on all objects I have examined) seems to start with exactly 
one R_MIPS_NONE then valid relocations follow.

> > In theory all relocations that come after RELSZ/RELENT should be 
> > R_MIPS_NONE as they presumable would not be needed.  This should be 
> > 361731 - 332723 == 29008 unneeded relocation slots in the end of .rel.dyn.
>
>
> Does this match what you get from readelf -Dr, which will use the
> dynamic tags to locate the relocations?

readelf -Dr reports exactly DT_RELSZ bytes.  But that is the problem. 
DT_RELSZ is incorrect.

> > You can see that there are quite a few needed relocations that will not 
> > be done.
>
>
> But not on the order of 29,000, right?  Just the hundred or so that you
> pasted?

Correct.

It should be noted that my libgcj.so.5 (from gcc-3.4.3) does not suffer 
from this problem, but it is quite a bit smaller ( RELSZ= 609600 instead 
of 2661784).  Also libgcj.so.? from gcc-4.1 is similarly broken.

David Daney.