GNU Tools Cauldron SFrame talk notes

[Fangrui Song]

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.

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.

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.
Full .sframe merge into linkers should only be considered after this
section has conclusively proved its value and stability over
established unwind mechanisms.