This is the mail archive of the binutils@sources.redhat.com mailing list for the binutils project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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


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.

> 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?

> 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?

-- 
Daniel Jacobowitz
CodeSourcery, LLC


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]