n32, irix 6.5, bfd

[Timothy Daly <remote_bob at yahoo dot com>]

When linking n32 objects with the ld from cvs, I get the following
problem:

/usr/local/bin/ld: final link failed: Bad value

The tiny patch to elf32-mips.c at the end of this message fixed it -
but it's almost certainly not correct.  

According to the mips abi supplement, when a relocation of type
R_MIPS_GOT16 refers to a local symbol, it must be followed
immediately by an R_MIPS_LO16 relocation.  I think that it's actually
correct to bail from _bfd_mips_elf_relocate_section() if no
R_MIPS_LO16 reloc is found.  I rather think that something's funny in
the predicate mips_elf_local_relocation_p(), in particular lines
590[12]:

  if (elf_bad_symtab (input_bfd) && local_sections[r_symndx] != NULL)
    return true;

I think that there's something fishy about elf_bad_symtab.   Higher
up, around 2880, I see:


boolean
_bfd_mips_elf_object_p (abfd)
     bfd *abfd;
{
  /* Irix 5 and 6 are broken.  Object file symbol tables are not
always
     sorted correctly such that local symbols precede global symbols,
     and the sh_info field in the symbol table is not always right. 
*/
  if (SGI_COMPAT(abfd))
    elf_bad_symtab (abfd) = true;


So, if I understand correctly, on Irix 5 and 6, we cannot tell if a
symbol is local.  Therefore we cannot tell if we should expect an
R_MIPS_LO16 after an R_MIPS_GOT16.  Perhaps the best solution is to
also wrap the change below in an "if (SGI_COMPAT(abfd))" ?  Any hints
for a better solution?

Thanks,
Tim

===================================================================
RCS file: /cvs/src/src/bfd/elf32-mips.c,v
retrieving revision 1.145
diff -r1.145 elf32-mips.c
7415c7415
< 		    return false;
---
> 		    continue;

__________________________________________________
Do You Yahoo!?
Send FREE Valentine eCards with Yahoo! Greetings!
http://greetings.yahoo.com