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

[Ian Lance Taylor <ian@zembu.com>]

   From: Mark Mitchell <mark@codesourcery.com>
   Date: Tue, 28 Sep 1999 00:59:56 -0700

     @@ -6628,26 +6629,11 @@ _bfd_mips_elf_relocate_section (output_b
		       l &= lo16_howto->src_mask;
		       l = mips_elf_sign_extend (l, 16);

     -		  /* Save the high-order bit for later.  When we
     -		     encounter the R_MIPS_LO16 relocation we will need
     -		     them again.  */
		       addend <<= 16;
     -		  last_hi16_addend = addend;
     -		  last_hi16_addend_valid_p = true;

		       /* Compute the combined addend.  */
		       addend += l;
		     }
     -	      else if (r_type == R_MIPS_LO16) 
     -		{
     -		  /* Used the saved HI16 addend.  */
     -		  if (!last_hi16_addend_valid_p)
     -		    {
     -		      bfd_set_error (bfd_error_bad_value);
     -		      return false;
     -		    }
     -		  addend |= last_hi16_addend;
     -		}
		   else if (r_type == R_MIPS16_GPREL)
		     {
		       /* The addend is scrambled in the object file.  See

   Why is all this code going away?  This looks like it will make
   R_MIPS_LO16 not work in .rel sections.  The addend for the LO16
   relocation is the combination of bits in the HI16 and LO16 relocs, I
   think.

When computing the addend for a LO16 relocation, you don't need any
information from the HI16 relocation.  That's just math: the HI16
relocation can only contribute to the upper 16 bits, which the LO16
relocation doesn't use.  (The reverse is not true, because the LO16
relocation bits can carry into the HI16 relocation bits).

I think Geoff is trying to restore an extension we used to have, which
is to permit a LO16 relocation without a HI16 relocation.

Ian