From mboxrd@z Thu Jan 1 00:00:00 1970 From: Ian Lance Taylor To: mark@codesourcery.com Cc: geoffk@ozemail.com.au, gavin@cygnus.com, binutils@sourceware.cygnus.com, brendan@cygnus.com Subject: Re: Reloc changes to bfd/elf32-mips.c Date: Tue, 28 Sep 1999 06:57:00 -0000 Message-id: <19990928135607.6136.qmail@daffy.airs.com> References: <199909271118.VAA01663@gluttony.geoffk.wattle.id.au> <19990928005956V.mitchell@codesourcery.com> X-SW-Source: 1999-09/msg00190.html From: Mark Mitchell 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