[PATCH] bfd: include: sframe: fix PR ld/32789

[Indu Bhagat]

On 12/16/25 11:12 PM, Jan Beulich wrote:
> On 16.12.2025 23:52, Indu Bhagat via Binutils wrote:
>> Currently, when SFrame sections are emitted after linking the input
>> SFrame sections, the SFrame FDEs are sorted on start PC.  Doing so for
>> relocatable links has no effect (SFrame FDEs remain in place), because
>> the start PC is unrelocated data.  For relocatable links, then, the
>> emitted SFrame FDEs in the output section remain in the same order as
>> that in the respective input BFD.
>>
>> The assembler does not guarantee the emission of SFrame FDEs in the same
>> order as the placement of the associated .text* sections,
>> (SFRAME_F_FDE_SORTED is not set by ET_REL generated by GAS).  This means
>> setting SFRAME_F_FDE_SORTED by the linker was wrong when:
>>    - doing relocatable link, and
>>    - the input bfds contain multiple .text sections, say .text.hot,
>>      .text.init, .text.unlikely etc.
>>
>> For relocatable links, skip sorting the SFrame FDEs.  Do not set
>> SFRAME_F_FDE_SORTED for relocatable links.
>>
>> This is achieved by adding an explicit argument (bool sort_fde_p) to the
>> sframe_encoder_write API.  Move the API from 2.0 to the 2.1 node as this
>> is an ABI-incompatible change.  Skip bumping the "current" in
>> libsframe/libtool-version ATM, we will do so closer to release.
> I keep being concerned of such movements, but it also remains unclear to
> me whether the library is actually intended for any out-of-tree
> consumption. If it is, shouldn't the existing API stay in 2.0, with its
> implementation simply being a thin wrapper around the new (2.1) API?
> 

The library is not meant for out-of-tree consumption. But it is an 
installed .so, so I followed the general recommendation.

Is there is a way to convey that this is not meant for out-of-tree 
consumption ?

> And then I would wish the patch subject was more descriptive. Mentioning
> a PR alone means you force people to either read through enough of the
> description, or go look up the PR, to know what the patch is about.
> 

Will take care next time.

> Otherwise looks okay to me, for whatever that's worth.

Thanks for reviewing,