[RFC 25/28] [SFrame-V3] ld: add --no-sframe-info command line option

[Jan Beulich]

On 22.12.2025 21:24, Indu Bhagat wrote:
> On 12/22/25 7:27 AM, Jan Beulich wrote:
>> On 09.12.2025 10:07, Indu Bhagat via Binutils wrote:
>>> Add a new command line option `--no-sframe-info` to the linker. This option
>>> allows users to prevent the linker from generating .sframe sections,
>>> including the linker-generated (internal) SFrame sections for PLT entries.
>>>
>>> Previously, the existing `--no-ld-generated-unwind-info` option
>>> controlled whether (not just .eh_frame for PLT entries, but also) SFrame
>>> for PLT entries. This change decouples SFrame from other unwind formats
>>> (like .eh_frame), allowing for more control over the output binary's
>>> SFrame data.
>>>
>>> The option is added for architectures that currently support SFrame:
>>> AArch64, s390x, and x86_64.
>>>
>>> In a subsequent commit, we will tie this option with discard of all
>>> input .sframe sections.
>>
>> Note how the present field is "no_ld_generated_unwind_info", i.e.
>> affecting only linker generated data (if the name is to be trusted).
>> Discarding input .sframe sections gets in conflict with what a linker
>> script may be saying. While perhaps tolerable for the built-in ones,
>> I'm not sure this is desirable behavior at least for people's custom
>> scripts.
> 
> (Adding Sam and Augustine)
> 
> The rationale for this option is: Consider the case when say, the distro 
> is shipped with SFrame sections in the installed binaries/libraries. A 
> user application using these installed libraries, but not enabling 
> .sframe for itself just yet, will see an output .sframe corresponding to 
> the pulled in libraries.  This is "partial" .sframe information for the 
> application.  The option for user, if they want to turn off the .sframe 
> section completely will be to edit the linker script; something that I 
> thought may not be preferable ?
> 
> Is editing the linker script for removing .sframe section from output 
> acceptable and considered a well-received solution ?

For people already using custom scripts - perhaps. For people not using
any (likely the majority), that's an undue burden imo.

I like Augustine's option name suggestion - that together with clear
documentation of the wider effect may be good enough to (mostly)
eliminate my concern.

Jan