[PATCH 4/8] bfd/ELF: fold BFD_RELOC_<arch>_GOTOFF*

[Hans-Peter Nilsson]

On Mon, 16 Mar 2026, Michael Matz wrote:
> Hello,
> 
> On Sat, 14 Mar 2026, Hans-Peter Nilsson wrote:
> 
> > > On 3/13/2026 10:54 AM, Jan Beulich wrote:
> > > > For many of the cases there's no need to have separate relocs per arch;
> > > > just like for other more or less generic ones a single one (per purpose;
> > > > a 64-bit generic one is being introduced) will do. Arm64, C-Sky, and
> > > > KVX - sadly - continue to be exceptions.
> > > 
> > > Hello Jan, hopefully you don't mind my perhaps newbie question:
> > > 
> > > Isn't the removal of e.g. BFD_RELOC_390_GOTOFF64 breaking the existing
> > > external BFD API?  At least all of these relocations are documented in
> > > the BFD documentation:
> > > https://sourceware.org/binutils/docs/bfd.html#index-BFD_005fRELOC_005f390_005fGOTOFF64
> > 
> > Of course not; if it had been part of an important external ABI, 
> > there would have been coverage in the binutils testsuite and Jan 
> > would have noticed that way.
> > 
> > (Yes, that was tongue-in-cheek and all that, just hoping to make 
> > a certain point wrt. test-case importance, and FAOD not directed 
> > at neither you nor Jan.)
> 
> There never was an "existing external BFD API".
> [...]

My bad choice of words "external ABI"; I did not mean libbfd.
(Having said that, it happens to also be covered by that 
statement; it's not an "important external ABI".)

I meant existing binutils functionality as in e.g. input to gas 
and other input objects, implying certain object output.

For example, in a slightly worse world, this could have affected 
the gas .reloc pseudo, but AFAICT it doesn't.

brgds, H-P