GNU Tools Cauldron SFrame talk notes

[Indu Bhagat]

On 10/18/25 10:34 AM, Fangrui Song wrote:
> On Thu, Oct 16, 2025 at 1:14 AM Florian Weimer <fweimer@redhat.com> wrote:
>>
>> * Fangrui Song:
>>
>>> The version mix-and-match problem requires a concrete solution—we cannot
>>> defer it. Concatenation with opt-in indexing is the only viable approach
>>> that handles all scenarios.
>>
>> Is this exactly true?  What about generating SFrame data in the linker
>> from the existing DWARF EH data?
>>
>> This would not work automatically for kernel modules because generating
>> SFrame data should not be the default for relocatable links.  Maybe an
>> --sframe-index option for ld or objcopy would be acceptable?  Kernel
>> modules do not have the usual post-processing problems because they are
>> relocatable, and their build is typically controlled by the kernel's
>> build system.
>>
>> Thanks,
>> Florian
> 
> This alternative design makes the assembler's .sframe section
> unnecessary and is worth exploring.
> This design allows the linker to merge and optimize the .eh_frame
> section as usual (which requires CIE and FDE boundary information).
> The linker then analyzes the CFI instructions (a step previously
> unneeded) and generates the .sframe section.
> Since the linker only reads the stable .eh_frame and produces .sframe,
> there's no mix-and-match concern.
> 
> CFI instruction decoding introduces additional complexity. However,
> this is balanced by the architectural advantage of centralizing the
> logic;
> it avoids scattering processing code (similar to SHF_MERGE and
> .eh_frame) across the linker code.
> However, this fine-grained knowledge of the format may expose the
> linker to more frequent updates—a serious risk, given that the
> linker's foundational role in the build process demands exceptional
> stability and robustness.
> 

I agree with the observation of this route introduces additional 
complexity.  I'd expect the overhead of parsing DWARF CFI and processing 
CFI to generate SFrame data at link time to be more than what we have 
today (merging input SFrame data at link-time).

I am also not sure ATM about how will this fit in the linker workflow 
(and if managing this itself brings additional section specific handling 
in the generic linker parts): There are linker generated .eh_frame 
sections (for .plt* sections), which are merged to create the final 
.eh_frame output.  The suggested process of SFrame data creation will 
need to be deferred until such merging of EH Frame data is complete...

> A key related technical point concerns the section flags: we must
> confirm if .sframe truly requires the SHF_ALLOC flag.
> perf supports .debug_frame (tools/perf/util/unwind-libunwind-local.c),
> which does not have the SHF_ALLOC flag. Removing SHF_ALLOC from
> .sframe would significantly simplify the process for any post-link
> tool seeking to append or modify the unwind information, allowing them
> to add new sections with greater ease.
> 

SFrame requires SHF_ALLOC.

This ensures that SFrame is available in the program memory. 
Non-SHF_ALLOC SFrame will hurt tracers, and in-process stack tracing 
usecases, because the cost of mmap is not amortized over the runtime of 
the application. Cost is one only aspect; in some critical scenarios at 
the time when backtrace is needed, bringing in a section is not viable.

RE: perf supports .debug_frame which is SHF_ALLOC.
There is a difference between status quo and whether the status quo is 
the best we can do.

> A more cautious and immediate strategy is available: existing Linux
> distribution post-processing tools can be modified to append the
> .sframe section to executable and shared object files.

@Fangrui,
Do you think this intermediate solution is usable to build the huge 
fleet of a variety of userspace packages for a distro ?  How can one 
then test the fleet with SFrame data ?

> Full .sframe merge into linkers should only be considered after this
> section has conclusively proved its value and stability over
> established unwind mechanisms.

Integrating support for SFrame in GNU ld has undeniably helped with 
adoption and maturation of the format, with close attention to feature 
set and implementation fixes from the wider GNU/Linux community.  The 
feature set of V3 is a curated list of developers' inputs and feature 
requests possible only because of complete support available in the 
assembler/linker.

We are going in circles here again on this one, so I will say no more.

Thanks
Indu