This is the mail archive of the binutils@sourceware.org mailing list for the binutils project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

[PATCH] MIPS/GAS: Complain about missed fixups


Hi,

 This is really the same case as was with HI16 relocations before their 
handling was corrected as a part of this issue, except that it applies to 
several other relocations.  The case is as follows: an expression is not 
fully resolved at append_insn time, a fixup is created.  Later on the 
expression turns out constant (e.g. forward symbol references are 
satisfied) and by the time md_apply_fix is called it has been fully 
evaluated.  However md_apply_fix does nothing about it, any outstanding 
relocation decays to nil and the relocatable field remains initialised to 
zero as final output is produced.

 One such case is code like this:

0:
	li	$2, %higher(1f - 0b)
	[...]
1:

Of course code like above makes little sense, the distance between 0 and 1 
would have to be over 2GB for the relocation to come out as non-zero.  So 
there is little point in bending backwards and adding extra code to apply 
this relocation in md_apply_fix.  The same stands for %highest for 
example, however to complement the %hi/%lo fix I think this have to be 
caught just in case someone does something weird (at which point we may 
decide to implement the missing bit after all).

 Then I am not even sure what kind of calculation is supposed to be made 
for cases like:

0:
	li	$2, %got(1f - 0b)
1:

and several other ones.  However I don't think such an expression should 
be silently ignored, it's almost certainly a sign of a user error, so I 
think proper diagnostics needs to be added to warn about the situation.

 As this can be triggered with user code I have decided the diagnostics 
should be a proper error message and not an internal failure (which is BTW 
the case for the same relocations resolved straight away in append_insn, 
e.g. li $2, %got(0); fixed with another patch).  Regression-tested for 
MIPS targets with no problems; I have put it through a GCC/glibc build 
just to be sure it does not uncover a problem there.

 OK to apply?

2012-09-21  Maciej W. Rozycki  <macro@codesourcery.com>

	gas/
	* config/tc-mips.c (md_apply_fix): Complain about missed fixups.

  Maciej

binutils-gas-mips-fixup-error.diff
Index: binutils-fsf-trunk-quilt/gas/config/tc-mips.c
===================================================================
--- binutils-fsf-trunk-quilt.orig/gas/config/tc-mips.c	2012-09-17 22:18:33.000000000 +0100
+++ binutils-fsf-trunk-quilt/gas/config/tc-mips.c	2012-09-17 22:19:20.450746744 +0100
@@ -15521,6 +15521,9 @@ md_apply_fix (fixS *fixP, valueT *valP, 
     case BFD_RELOC_MICROMIPS_GOT_LO16:
     case BFD_RELOC_MICROMIPS_CALL_HI16:
     case BFD_RELOC_MICROMIPS_CALL_LO16:
+      if (fixP->fx_done)
+	as_bad_where (fixP->fx_file, fixP->fx_line,
+		      _("Unsupported constant in relocation"));
       /* Nothing needed to do.  The value comes from the reloc entry.  */
       break;
 


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]