Changes/SFrameInBinaries

Binaries compiled with SFrame data

This is a proposed Change for Fedora Linux.
This document represents a proposed Change. As part of the Changes process, proposals are publicly announced in order to receive community feedback. This proposal will only be implemented if approved by the Fedora Engineering Steering Committee.

Summary

During Fedora package builds, configure the ELF toolchain in such a way that userspace ELF binaries contain SFrame data. This data helps performance data.

Owner

• Name: Florian Weimer
• Email: fweimer@redhat.com

Current status

• Targeted release: Fedora Linux 43
• Last updated: 2025-06-30
• [<link to devel-announce post will be added by Wrangler> Announced]
• [<will be assigned by the Wrangler> Discussion thread]
• FESCo issue: <will be assigned by the Wrangler>
• Tracker bug: <will be assigned by the Wrangler>
• Release notes tracker: <will be assigned by the Wrangler>

Detailed Description

SFrame is a relatively new data format that can be embedded in ELF binaries, to aid crash dumping and performance tools. It allows reliable backtrace generation (as long as the stack is not corrupted), with or without frame pointers. SFrame data is not removed as part of debuginfo processing, and resides in a loadable segment. This means that if the whole distribution is built with it, it can be used without the need for downloading or installing additional data files.

SFrame data is more compact than the PT_GNU_EH_FRAME data that Fedora already includes in binaries. Due to it's simplified nature, it is expected that in time for the Fedora 43 release, there will built-in kernel support for decoding this data in profiling interrupts (for use with perf; patches are already under review) and, later on, for access via (e)BPF as well. This situation is different from the DWARF unwinding data, which could be interpreted within the kernel as well, but it is generally believed that DWARF processing in the kernel will not be accepted for inclusion in the kernel.

Building with frame pointers significantly changes the amount and nature of SFrame data. Fedora ELN currently builds the x86_64 distribution with frame pointers (despite this not being the Red Hat Platform Tools plan for RHEL 11). We need a distribution without frame pointers to evaluate the usefulness of SFrame data for traceback generation, so we are changing ELN back to follow upstream/ABI defaults for frame pointers.

There is no plan to stop including DWARF unwinding information (PT_GNU_EH_FRAME) because it is required by Fedora's -fexceptions build flag for C (and not just for C++).

Benefit to Fedora

The current level of

• Frame pointers for unwinding cause the second stack frame to get dropped if the frame at the top of the stack is interrupted before it had a chance to set up the frame pointer.
• GCC suports building with frame pointers, but it does not undertake steps to ensure that the frame pointer is valid for the majority
• GCC optimizations such as shrink-wrapping (that restrict frame maintenance to execution regions that need them) and scheduling of prologues and epilogues become more sophisticated over time.
• Library authors are increasingly aware of these optimizations and write code accordingly. For example, the fast path in malloc in glibc 2.42 does not set up a frame pointer on AArch64 or x86-64 (even with -mno-omit-leaf-frame-pointers).
• ELF dynamic linking depends on PLT stubs. Those cannot set up a frame pointer because they must end in a tail call.

Scope

• Proposal owners: Change the build flags in redhat-rpm-config. Verify that the toolchain works, and that the major Fedora linkers have sufficient compatibility.

• Other developers: binutils, lld, mold linkers will generate SFrame data. They may require backporting of additional upstream patches to support relocatable links.

• Release engineering: #Releng issue number (change requires mass rebuild with updated toolchain)

• Policies and guidelines: N/A (not needed for this Change; buildflags.md in redhat-rpm-config will reflect the change in build flags)

• Trademark approval: N/A (not needed for this Change)

• Alignment with the Fedora Strategy: This change falls under programming language stack ecosystems.

Upgrade/compatibility impact

Older linkers will not produce correct SFrame sections from the section data they find in the input files (just concatenating the sections is no longer enough). The binaries will still execute (as long that does not depend on accurate backtraces), but the SFrame data will be corrupted.

The most widely linkers in Fedora will be updated before the Fedora 43 release.

Early Testing (Optional)

Do you require 'QA Blueprint' support? N

How To Test

End user testing depends on how tools integrate this. It is possible that tools like perf will autodect kernel support and automatically enable SFrame enhanced backtraces if the user requests callgraphs (e.g., perf top -g).

Contingency Plan

• Contingency mechanism: (What to do? Who will do it?) The extra SFrame data can easily be ignored in non-relocatable objects (main programs and shared objects). In case of reloctable ELF files (.o and static libraries/.a), we may have to do some target, leaf-only rebuilds to remove the SFrame if the SFrame data is disruptive to linkers.
• Contingency deadline: beta freeze
• Blocks release? No

Documentation

N/A (not a System Wide Change)