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