This is the mail archive of the
binutils@sources.redhat.com
mailing list for the binutils project.
Re: mips: disable combreloc for NEWABI
On Oct 19, 2002, Jakub Jelinek <jakub@redhat.com> wrote:
> Well, all mips relocs are in fact not RELATIVE
R_MIPS_REL32 is the only relocation I find in large shared libraries
generated for o32, n32 and n64.
> but anyway, this has nothing to do with RELATIVE or not RELATIVE,
> but mainly with whether relocations against the same symbol are
> consecutive or not.
I see. Earlier, I had got the impression that R_MIPS_REL32 would
never take a symbol, so it would always be relative to the load
address. Now I realize this is not the case.
> If mips does the sorting in elf*mips.c, then fine, but one has to
> wonder why it cannot use the generic sorting and do the merging of
> relocs against the same r_offset before the generic sorting.
> If it does not, then it will hurt performance badly.
This is also explained in the patch: elf64-mips.c packs 3 consecutive
relocations into one, and the swap in/out functions expect to receive
a pointer to the first of the three relocations, such that it can
access the relocations that follow by indexing the pointer.
This doesn't work with REL relocations in elf_link_sort_relocs,
because struct elf_link_sort_rela is used that contains a single
relocation, instead of as many as specified as the grouping factor of
relocations.
Now that I realize sorting relocations is actually useful for n32 and
n64, I'll try to fix the relocation-sorting code so as to cope with
this situation.
Thanks for enlightening me.
--
Alexandre Oliva Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/
Red Hat GCC Developer aoliva@{redhat.com, gcc.gnu.org}
CS PhD student at IC-Unicamp oliva@{lsd.ic.unicamp.br, gnu.org}
Free Software Evangelist Professional serial bug killer