[PATCH v2 02/10] GAS: Unify code for SET_SECTION_RELOCS call

[Jan Beulich]

On 08.11.2025 15:55, Maciej W. Rozycki wrote:
> On Fri, 7 Nov 2025, Jan Beulich wrote:
> 
>>> Fold a separate call to `bfd_set_reloc' into SET_SECTION_RELOCS itself, 
>>> so that the GAS interface to this facility is contained in a single 
>>> invocation.
>>>
>>> Set the macro by default to a plain call to `bfd_set_reloc', letting 
>>> backends override the macro, with the requirement now to factor in a 
>>> call to said function.  Update the COFF variant accordingly, moving it 
>>> to a new function for a better code structure, retaining functionality.
>>>
>>> This is in preparation for `bfd_set_reloc' to return an error status.
>>
>> It's not becoming clear to me how this will end up being useful. In gas
>> there's a single call site right now. Hence only a single place where
>> you would need to make adjustments. Whereas with the change in place,
>> in order to handle the error status, you will need to make changes in
>> at least two places.
> 
>  That is not true, `bfd_set_reloc' is called both by `write_relocs' and by 
> `obj_mach_o_reorder_section_relocs',

Hmm, I must have managed to overlook that in grep output. Yet then it's
going to be three places that need touching to deal with the error status
you add subsequently.

As an aside, Mach-O may be a particularly bad example. It looks pretty
much unmaintained / unfinished, and hence I have already raised the question
of whether we really want to keep (partial) support for in in binutils. I'll
need to re-raise that in a more targeted way ...

> and this change makes it called only 
> once, improving code structure and making error handling straightforward.  
> Backends can choose whether to call `bfd_set_reloc' first (such as COFF) 
> or last (such as Mach-O) in relation to their own additional actions.
> 
>  I could have mentioned this peculiarity in the change description, but it 
> has been lost in processing since I wrote this piece long ago.  The change 
> description stands regardless, it's an obvious cleanup.

"Obvious" as in your personal view. Without that Mach-O aspect (where,
while benign afaict, the function oddly is called a 2nd time right now,
once ahead of the SET_SECTION_RELOCS() invocation and once in the course
of it) it's pretty much non-obvious to me. You're hiding a particular call
inside a (rarely used and imo improperly named) macro.

Jan