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

[David Daney <ddaney at avtrex dot com>]

Richard Sandiford wrote:
> David Daney <ddaney@avtrex.com> writes:
>
> > 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.
> >
> > However if I do:
> > [daney@dl2 .libs]$ mipsel-linux-readelf -W -r libgcj.so.6 | tail -n 
> > 29008 | more
> > 0105414c  00a06903 R_MIPS_REL32           00fc0bc0 
> > _ZN5javax8security4sasl13SaslException6class$E
> > 01056428  00a06a03 R_MIPS_REL32           0099fd24 
> > _ZN5javax5swing4text28DefaultEditorKit$PasteActionC1Ev
> > 00dfe64c  00a06b03 R_MIPS_REL32           00fe6a50 
> > _ZN3gnu3xml9transform15CurrentFunction6class$E
> > [...]
> > You can see that there are quite a few needed relocations that will not 
> > be done.
>
>
> Are there any other R_MIPS_NONE relocations before the cut-off point?
> (Besides the first one, I mean.)  It sounded from your message like you
> might have checked, and that (as expected) there weren't, but I just
> wanted to make sure.

There are none.  The relocations are sorted so they all end up at the 
end.  As I said in the other message:  The problem is that dynamic 
relocations for the non-primary gots are being added after DT_RELSZ is 
calculated.

I am working on a patch.

David Daney