bfd relocation handling questions

[Alan Modra]

On Wed, Apr 07, 2021 at 03:42:52PM -0700, H.J. Lu wrote:
> On Wed, Apr 7, 2021 at 1:50 AM Jan Beulich <jbeulich@suse.com> wrote:
> >
> > On 07.04.2021 04:36, Alan Modra wrote:
> > > On Tue, Apr 06, 2021 at 09:22:22AM +0200, Jan Beulich wrote:
> > >> initially I only meant to look into making x86's @size also work when
> > >> the final link produces non-ELF output from ELF object files. But I
> > >> ran into more general issues, which I'd like to gain some understanding
> > >> on first. While my looking into this was x86 focused, I expect there's
> > >> on little x86-specific-ness there.
> > >>
> > >> It looks to me as if not only the x86 assembler (I'll bring this up as
> > >> a separate topic, perhaps by way of proposing one or more patches) but
> > >> many parts of binutils behave differently for 32-bit targets depending
> > >> on whether the bfd build is a BFD64 one. There are a few comments
> > >> indicating that overflow checking would actually require a wider type
> > >> for the calculations to be done in, but architectures where addresses
> > >> wrap (x86, x86-64) would presumably not want such overflows to be
> > >> detected anyway when the relocated item is a full-address-width one.
> > >> IOW I suspect that for x86 a BFD64 build would report overflows that
> > >> it shouldn't report.
> > >>
> > >> This is (I think) closely connected to the use of complain_overflow_*
> > >> in the howto entries.
> > >
> > > Yes.
> > >
> > >> Is there much sense in marking full-address-
> > >> width relocations as complain_overflow_unsigned or
> > >> complain_overflow_bitfield? Besides the BFD64 and wrapping aspects
> > >> above, these two overflow checking variants are effectively a more
> > >> involved way of complain_overflow_dont as long as all arithmetic is
> > >> done with bfd_vma values. Is their use, when an architecture does not
> > >> wrap addresses (if any such exists in the first place), purely for
> > >> documentation purposes?
> > >
> > > A lot of BFD is quickly hacked together code copied from somewhere
> > > with minimal editing until "it worked".  Relocation howtos are
> > > particular bad since a lot of targets only use the entire howto when
> > > producing foreign output, and quite a few disable foreign output
> > > entirely (eg. "ld --oformat srec" gives an error on arm, aarch64,
> > > avr).
> > >
> > > So I wouldn't presume that complain_overflow_* was "documenting"
> > > anything.  It's far more likely that someone copied the howto from
> > > some other reloc and didn't update to complain_overflow_dont.
> >
> > IOW changing some of them would likely be a plausible thing to do.

Yes.

> > What I'm missing though is some clarification on the differing
> > behavior for 32-bit targets in BFD64 vs non-BFD64 builds. Is this
> > intentional? Or does this again just "happen to be that way"?
> > (As an aside, with the move to C99 I think it would at least be
> > an option to force BFD64 builds uniformly.)
> >
> > H.J. - any thoughts here towards intended new behavior for x86
> > in particular? Would you see a reason to keep any of the full-width
> > relocations using anything else than "dont"? Plus ...
> 
> 32-bit targets in BFD64 should behave the same as non-BFD64 builds.
> If not, it is a bug.

Agreed.

-- 
Alan Modra
Australia Development Lab, IBM