* Miro Hrončok:
* #2923 Re-vote for Change proposal: Add -fno-omit-frame-pointer to
default (mhroncok, 17:06:26)
is the implementation (davide, 17:13:47)
* AGREED: APPROVED (+6,1,-1) This Change is implemented for Fedora
Linux 38 and we evaluate whether to retain it by Fedora Linux 40.
This Change must be implemented in a manner which packages are able
to trivially opt-out of retaining frame pointers during compilation
so that packages that take larger performance hits can easily
revert. (mhroncok, 17:20:38)
* Change owners please coordinate the change with the Python
Maintainers before changing the defaults (mhroncok, 17:21:20)
The change as voted simply does not work at a technical level because
-mno-omit-leaf-frame-pointer is an architecture-specific GCC option that
is not available on all Fedora architectures. I don't think
-fno-omit-frame-pointer is well-exercised on s390x, so I wouldn't want
to use it there, either.
Is it safe to assume this change (as voted) is actually intended for
x86_64 only, in both directions? Specifically, that opting out will
*not* disable frame pointers on aarch64 and ppc64le (where it would
result in an ABI break)?
We should not ask package maintainers to debug i686 build failures
related to inline assembly and register shortage. (On i686, it's
impossible to make certain system calls while preserving a frame
pointer.) As far as I understand it, building i686 with frame pointers
isn't in scope for the change, either, because it does not further its
Regarding leaf functions, on typical workloads, a significant fraction
of the profiling samples will be in glibc string functions, which do not
have frame pointers. So any profiler has to cope with leaf functions
with frame pointers anyway. As a result, do we really need the
On aarch64, we should not use -mno-omit-leaf-frame-pointer because there
is no skipped frame problem with backtraces: the link register (x30) can
be read directly even in leaf functions. The ABI only mandates frame
pointers for non-leaf functions. On ppc64le, GCC does not even support
This is why I think the change is implicitly just for x86_64.
Does anybody know how this change invalidates Fedora binaries as a
reference for DWARF performance work? Do the generated .eh_frame data
change materially once frame pointers are in use?