Re: [RFA] ARM OABI - pc-relative relocations

[Richard Earnshaw <rearnsha at arm dot com>]

> Alan,
> 
> Thank you for your quick answer.
> 
> Alan Modra (amodra@bigpond.net.au):
> 
> > On Fri, Dec 12, 2003 at 09:49:36PM +0100, Jerome Guitton wrote:
> > >    c:   ebfffffb        bl      0 <r>
> > > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> > > 
> > > Here is the problem. Even though arm-oabi uses RELA, an implicit addend
> > > has been generated (-0xc). The relocation entry is:
> > 
> > This shouldn't really matter.  When applying a reloc, RELA targets are
> > supposed to ignore the section contents in the field that the reloc
> > replaces.
> 
> That would make sense; but that's not the way I understand the ARM ELF
> specification (section 4.4: relocation types):
> 
> [...]
> The table , ARM relocation types, below, describes the computation
> performed by each type of ARM relocation directive, using the
> following notation:
> 
> 'A' denotes the addend used to compute the new value of the storage unit
> being relocated.
> 
> - It is the value extracted from the storage unit being relocated
> (relocation directives of sort SHT_REL) or the sum of that value and
> the addend field of the relocation directive (sort SHT_RELA).
> [...]
> 

BTW I think you must have an out of date document.... In ARM ELF (SWS ESPC 
0003 B-02), which was the final draft, the text is now in section 4.5

The original ARM ELF specification was based on the TIS ELF documents 
(which are now obsolete), these documents were much less precise than the 
current ELF specs and obviously this was a valid interpretation at that 
time.  I must admit that in retrospect this decision seems a little 
perverse: perhaps the reason was to enable a more flexible conversion 
between REL and RELA relocs (though I believe the ARM tools only ever 
generated REL types).  The sole advantage of RELA relocations in the above 
scheme is that they can represent a greater variety of addends than can be 
managed in a REL type reloc.

In the "ABI for the ARM Architecture" (http://www.arm.com/products/DevTools
/ABI.html), we've gone back to the current ELF specs and taken a much more 
traditional approach, so now the REL and RELA addends follow the current 
rules.  This introduces a further benefit for RELA type relocations: 
idempotency -- you can reapply the relocation and you should get the same 
result.  This allows, for example, images to be re-positioned after 
linking if they preserve their relocations in RELA form.


> That is definitely what the binutils are doing for that target, and it is also
> what Tornado's loader for VxWorks is doing.
> 
> (I must say I fail to see any advantage of using RELA on ARM
> targets. The relocation record is bigger, and you still have to get
> the implicit addend...)
> 
> > Ah!  On looking at elfarm_oabi.c, I see that src_mask is non-zero on a
> > number of reloc howtos.  That's the real bug that needs fixing.  See the
> > description of src_mask in bfd/reloc.c.
> 
> Well, src_mask should be non-zero in this case, if I interpret
> correctly the ARM ELF spec.
> 

GNU tools have never fully implemented the previous ARM ELF 
specifications.  I'm hoping that's going to change for the new ABI, but my 
feeling for what should be done on the old standard is that you should 
adopt whatever is most expedient, provided it doesn't break any existing 
GNU code.

R.