bfd relocation handling questions

[H.J. Lu]

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.
>
> 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.


-- 
H.J.