Richard W.M. Jones wrote: > 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.
For updated information about SFrame https://sourceware.org/binutils/wiki/sframe. There is active involvement in many of the projects involving SFrame at this time, and the status is evolving. Indu -- _______________________________________________ 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
