On Sun, Jun 22, 2025 at 11:41:48AM +0200, Florian Weimer wrote: > The reason is what GCC calls shrink-wrapping. It's related to this old > optimization: > > Minimizing register usage penalty at procedure calls > <https://dl.acm.org/doi/abs/10.1145/53990.53999> > > Basically it pushes optional function prologue instructions (such as > saving callee-saved registers, or setting up the frame pointer) to the > code paths that actually need them. > > Given that most of the hot glibc functions do not use frame pointers (at > least not on their happy paths), PLT stubs do not have them, and there > is a race condition at the start of functions until the frame pointer is > set up, tools need to be aware that the top-most interrupted frame (or > the first frame after a signal frame) may use the caller's frame > pointer. This does not prevent frame pointer based unwinding because in > the impacted frames, the frame pointer register is not changed. Without > countermeasures, the immediate caller's frame just vanishes from > backtraces. > > Given how pervasive this effect is and that no problems have been > reported so far, I think we can drop -mno-omit-leaf-frame-pointer from > the build flags. > > Thoughts?
Seems reasonable. The benefit of frame pointers is to get fast, very low overhead stack traces that point you to the general area of the problem. It's not an issue (in practice) that they're not completely accurate at the very tip of the stack. Unrelated to this, do you know how SFrame support (ie. in userspace) is going? This was/is the great hope for fast, low overhead stack traces without frame pointers, but it's all gone a bit quiet. The last thing I heard was a talk by Steve Rostedt a few years ago. Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones Read my programming and virtualization blog: http://rwmj.wordpress.com virt-builder quickly builds VMs from scratch http://libguestfs.org/virt-builder.1.html -- _______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
