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

David Daney ddaney@avtrex.com
Fri May 20 21:43:00 GMT 2005


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.



More information about the Binutils mailing list