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)?
I'd say we should just keep the spirit of the proposal in mind: to enable frame
pointers on all platforms where it's possible. Change owners are certainly not experts
on intricacies of each possible architecture, so it would definitely help to get help and
feedback from people like you on what specifically needs to be enabled to make this work
across all arches.
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
-mno-omit-leaf-frame-pointer option?
I think we should be careful about defining "typical workloads" and not assume
that it's mostly inside glibc. But even if it is, just because glibcs leaf functions
don't have frame pointers doesn't seem to imply that leaf pointers should be
generally left out. As I said above, the spirit of the proposal is to make stack traces as
accurate as possible. That includes leaf functions, right?
"any profiler has to cope with leaf functions" is true, but what is
"cope"? Some more advanced solutions combine LBR stacks with frame pointers and
are able to recover full stacks. But the space of stack trace uses (at least with BPF) is
vast. There will be BPF-based tools of various degree of sophistication, and I'm 100%
sure all of them won't go to the trouble of using LBR to recover the stack. Certainly
this won't happen with simple ad-hoc bpftrace scripts.
So that's just to say that I think we should try hard to get leaf frame pointers as
well so that stack traces are better in general. For glibc cases, we'll just get stack
traces without last level, unless we do something more complicated with LBR.
WDYT?
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
-mno-omit-leaf-frame-pointer.
This is why I think the change is implicitly just for x86_64.
Definitely not intentionally, might be just a bias of what we had most hands-on experience
with.