PERFORCE change 138282 for review
Oleksandr Tymoshenko
gonzo at FreeBSD.org
Sat Mar 22 15:05:23 UTC 2008
http://perforce.freebsd.org/chv.cgi?CH=138282
Change 138282 by gonzo at gonzo_jeeves on 2008/03/22 15:05:05
o Merge fix for "string merging bug" from binutils 2.18. Some
details can be found here:
http://www.sourceware.org/ml/binutils/2004-01/msg00248.html
Affected files ...
.. //depot/projects/mips2-jnpr/src/contrib/binutils/gas/config/tc-mips.c#2 edit
Differences ...
==== //depot/projects/mips2-jnpr/src/contrib/binutils/gas/config/tc-mips.c#2 (text+ko) ====
@@ -281,6 +281,9 @@
#define HAVE_64BIT_OBJECTS (mips_abi == N64_ABI)
+/* True if relocations are stored in-place. */
+#define HAVE_IN_PLACE_ADDENDS (!HAVE_NEWABI)
+
/* We can only have 64bit addresses if the object file format
supports it. */
#define HAVE_32BIT_ADDRESSES \
@@ -13020,6 +13023,26 @@
if (fixp->fx_addsy == NULL)
return 1;
+ /* If symbol SYM is in a mergeable section, relocations of the form
+ SYM + 0 can usually be made section-relative. The mergeable data
+ is then identified by the section offset rather than by the symbol.
+
+ However, if we're generating REL LO16 relocations, the offset is split
+ between the LO16 and parterning high part relocation. The linker will
+ need to recalculate the complete offset in order to correctly identify
+ the merge data.
+
+ The linker has traditionally not looked for the parterning high part
+ relocation, and has thus allowed orphaned R_MIPS_LO16 relocations to be
+ placed anywhere. Rather than break backwards compatibility by changing
+ this, it seems better not to force the issue, and instead keep the
+ original symbol. This will work with either linker behavior. */
+ if ((fixp->fx_r_type == BFD_RELOC_LO16
+ || reloc_needs_lo_p (fixp->fx_r_type))
+ && HAVE_IN_PLACE_ADDENDS
+ && (S_GET_SEGMENT (fixp->fx_addsy)->flags & SEC_MERGE) != 0)
+ return 0;
+
#ifdef OBJ_ELF
if (OUTPUT_FLAVOR == bfd_target_elf_flavour
&& S_GET_OTHER (fixp->fx_addsy) == STO_MIPS16
More information about the p4-projects
mailing list