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]

Re: [PATCH, RFA 1/3] BFD: Let targets handle relocations against absolute symbols


On Tue, 12 Jul 2016, Alan Modra wrote:

> > 	* reloc.c (bfd_perform_relocation): Try the `howto' handler 
> > 	first with relocations against absolute symbols.
> > 	(bfd_install_relocation): Likewise.
> 
> The patch looks reasonable to me, so OK.  Like you I'm a little
> concerned about existing howto->special_function behaving correctly
> with absolute symbols, but I guess we can fix any issues as we find
> them.  Did you perform any ld -r tests?

 Not originally, however now that you mentioned it I ran `ld -r' across a 
few of the test cases included with these patches, both o32 and n32 and 
the output is unchanged and correct without or with this change applied.  
I'd expect that actually -- whether the in-place addend is left untouched 
or rewritten on copying input to output does not matter because offsets 
from the absolute section do not change with incremental linking.

 Out of curiosity I picked a non-ELF target using in-place addends and 
PC-relative relocations, `i386-linuxaout'.  I tried code similar to my 
MIPS test cases, using the JMP instruction instead.  So interestingly 
enough it is unaffected by my change, because its `md_apply_fix' function 
(in gas/config/tc-i386.c) always initialises the relocated field, 
regardless of whether relocation is complete (`fixP->fx_done' is TRUE) or 
an external relocation is requested.  It uses `md_number_to_chars' for 
this purpose, ignoring any special function the relevant relocation's 
`howto' structure may have.

 The MIPS target's `md_apply_fix' function also initialises the relocated 
field, but only if `fixP->fx_done' is TRUE (with the use of a specialised 
handler, `mips16_immed_extend', for mangled MIPS16 encodings), deferring 
any outstanding relocations to BFD.  We could make the MIPS target mimic 
i386, but it does not appear to me to be a move in the right direction -- 
I'd rather made i386 defer to BFD as well, so that the processing of 
external relocations is made in one place, avoiding the risk of having 
disjoint sets of bugs across the places where relocation processing 
happens, and consequently reducing the maintenance burden.

 Especially as up to my change proposed here relocations against absolute 
symbols were the only exception handled differently.  Therefore, and with 
your approval, I have committed this change now (I have pushed the other 
two as well).  Thanks for your review.

  Maciej


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