inconsistencies if (at least) ELF relocation handling
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
> Of course otoh I'm unconvinced R_X86_64_32 using
> complain_overflow_unsigned is correct either. Imo it ought to be
Australia Development Lab, IBM
More information about the Binutils