> 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. _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
