Re: Reloc changes to bfd/elf32-mips.c

[Ian Lance Taylor <ian at zembu dot com>]

   Date: Wed, 29 Sep 1999 14:50:20 +1000
   From: Geoff Keating <geoffk@ozemail.com.au>

We are somehow talking at cross purposes.  I don't see why what you
are saying has much to do with what I am saying.

   >    If you have a 64-bit BFD, none of
   >    this is necessary, and you can just do the right thing.  The object
   >    format size is irrelevant, you'd have to do a similar thing to make a
   >    R_MIPS_64 reloc work in an elf64 file with a 32-bit BFD (but you'd have
   >    to do many many other things too).
   > 
   > I don't see why it matters whether you have a 64 bit BFD.  What
   > matters is how you compute the relocation.

   If you have a 32-bit BFD, you can't ask it to load a 64-bit value out
   of memory into a bfd_vma; it will abort.

Well, yes.  That's why we compute a 32 bit value, and then manually
sign extend it to 64 bits.

   > Since this is a 32 bit object file format, all the values going into
   > this computation are 32 bit values.  The correct way to compute the
   > value is to compute the 32 bit relocation, and to sign extend the 32
   > bit result to 64 bits when storing it in memory.

   The addend is stored as a 64-bit value.  I don't know if it should be
   considered to have all 64 bits significant (at present it isn't), but
   it's still 8 bytes long.

Well, yes.  All the values we can manipulate in a 32 bit object file
format are 32 bits long.  We can't even talk about a longer value.
There is no reason to consider the upper 32 bits of the 64 bit
relocation.  We just need to sign extend correctly, so that the
processor will load the address correctly with a 64 load instruction.

It's true that you can construct a case which uses the upper 32 bits
of a 64 bit relocation.  But since we are using a 32 bit object file
format, such a case is not supported.

The only reason to support R_MIPS_64 is to support the processor's 64
bit load instructions when loading an address, because gcc wants to
generate such instructions.  It's not because the linker can actually
produce 64 bit addresses; it can't.

   > This is a target calculation.  It's not immediately obvious why it
   > should depend upon the host facilities in any way.

   Certainly, you should get the same result.  You may need to get the
   result in a different way in a 32-bit BFD.

If the code gets identical results either way, then the change is OK.

   >    The original code used the R_MIPS_32 howto for a R_MIPS_64 reloc, but
   >    if you do that the addend gets computed wrong in big-endian files
   >    because BFD thinks the addend is 32 bits long and only sees the high
   >    32 bits which are not usually helpful.
   > 
   > Before Mark's rewrite, the code handled this correctly in
   > mips_elf_relocate_section:
   > 
   > 		  if (r_type == R_MIPS_64 && bfd_big_endian (input_bfd))
   > 		    r = _bfd_relocate_contents (howto, input_bfd,
   > 						addend,
   > 						contents + rel->r_offset + 4);
   > 
   > Perhaps this got dropped somewhere along the way.

   It seems so.

Actually, I still some code that seems relevant, under the comment

	  /* In the 32-bit VMA case, we must handle sign-extension and
	     endianness manually.  */

Ian