inconsistencies if (at least) ELF relocation handling

Alan Modra amodra@gmail.com
Tue May 4 23:32:03 GMT 2021


On Tue, May 04, 2021 at 08:49:54AM +0200, Jan Beulich wrote:
> But such multiple relocations to the same r_offset are spec compliant
> only with REL, not with RELA, as per my understanding.

My reading of the spec says RELA is supported too.

> >> As to the breakage on x86-64, I observe a number of "relocation
> >> truncated to fit: R_X86_64_32 against `.debug_str'", due to negative
> >> addends getting truncated to 32-bit unsigned values and this reloc
> >> using complain_overflow_unsigned. In ELF it is my understanding that
> >> addends - no matter what their origin - are always signed.
> > 
> > The ELF gABI does tend to give that idea by specifying r_addend as
> > signed, but I believe there are relocations that only allow positive
> > addends.  Processor ABIs are free to specify relocations like that..
> 
> Interesting. I would assume such targets then ought to handle such
> "non-standard" (I'm inclined to even say "non-conforming") relocations
> locally, rather than requiring generic code to cover for this (and
> break other targets)?

I guess the question only matters for REL targets where the addend
is read from section contents.  For complain_overflow_bitfield and
complain_overflow_signed _bfd_relocate_contents currently sign extends
the field read from section contents.  For complain_overflow_unsigned
_bfd_relocate_contents treats the field as unsigned.  That makes some
sense since complain_overflow_unsigned is used with relocations for
instructions that have an unsigned offset field.  So the field really
is unsigned in a final linked object.  However, that doesn't allow
negative addends in relocatable object files.  What breaks if you
change the semantics?  There aren't that many targets that are REL and
use complain_overflow_unsigned.

> Of course otoh I'm unconvinced R_X86_64_32 using
> complain_overflow_unsigned is correct either. Imo it ought to be
> complain_overflow_bitfield.
> 
> Jan

-- 
Alan Modra
Australia Development Lab, IBM


More information about the Binutils mailing list