This is the mail archive of the
binutils@sourceware.org
mailing list for the binutils project.
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