The state of SFrame (was: Re: Remove -mno-omit-leaf-frame-pointer from build flags)

LWN this week has a good article on the state of SFrame: https://lwn.net/Articles/1029189/ (gift link: https://lwn.net/SubscriberLink/1029189/03199ce0a0862a83/) Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones Read my programming and virtualization blog: h

Re: Remove -mno-omit-leaf-frame-pointer from build flags

* Kevin Kofler via devel: > Neal Gompa wrote: >> But those are hand-written directives, no? That approach doesn't scale at >> all. > > Handwritten unwinding information for handwritten assembly. C code has > compiler-generated unwinding information. And if you don't manipulate the stack pointer,

Re: Remove -mno-omit-leaf-frame-pointer from build flags

Neal Gompa wrote: > But those are hand-written directives, no? That approach doesn't scale at > all. Handwritten unwinding information for handwritten assembly. C code has compiler-generated unwinding information. Kevin Kofler -- ___ devel ma

Re: Remove -mno-omit-leaf-frame-pointer from build flags

On Mon, Jul 7, 2025 at 6:43 PM Frank Ch. Eigler wrote: > > Neal Gompa writes: > > > [...] So my semi-naive interpretation of the problem here is that > > glibc is special in that it doesn't provide any support for real-time > > tracing or profiling. [...] > > Note that glibc does support unwindi

Re: Remove -mno-omit-leaf-frame-pointer from build flags

Neal Gompa writes: > [...] So my semi-naive interpretation of the problem here is that > glibc is special in that it doesn't provide any support for real-time > tracing or profiling. [...] Note that glibc does support unwinding-based tracing/profiling via the .cfi directives even in assembly co

Re: Remove -mno-omit-leaf-frame-pointer from build flags

* Davide Cavalca: > On 2025-06-24 22:02, Florian Weimer wrote: >> Are you suggesting to move RHEL 11 development away from Fedora/ELN to >> CentOS Stream? Wouldn't that be implied by this approach? > > Not at all. My point was that if you want a platform to run > experiments, the CentOS ISA SIG s

Re: Remove -mno-omit-leaf-frame-pointer from build flags

On 2025-06-24 22:02, Florian Weimer wrote: Are you suggesting to move RHEL 11 development away from Fedora/ELN to CentOS Stream? Wouldn't that be implied by this approach? Not at all. My point was that if you want a platform to run experiments, the CentOS ISA SIG seems like a better fit, as i

Re: Remove -mno-omit-leaf-frame-pointer from build flags

On Tue, Jun 24, 2025 at 10:13 PM Florian Weimer wrote: > > * Andrii Nakryiko: > > > On Tue, Jun 24, 2025 at 11:08 AM Davide Cavalca > > wrote: > >> > >> On 2025-06-24 12:06, Florian Weimer wrote: > >> > Sorry, I tried to make clear that this is regular C code compiled with > >> > the -mno-omit-le

Re: Remove -mno-omit-leaf-frame-pointer from build flags

* Andrii Nakryiko: > On Tue, Jun 24, 2025 at 11:08 AM Davide Cavalca > wrote: >> >> On 2025-06-24 12:06, Florian Weimer wrote: >> > Sorry, I tried to make clear that this is regular C code compiled with >> > the -mno-omit-leaf-frame-pointer flag, like the rest of the >> > distribution. >> > >> >

Re: Remove -mno-omit-leaf-frame-pointer from build flags

* Davide Cavalca: > On 2025-06-22 16:17, Florian Weimer wrote: >>> 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 hea

Re: Remove -mno-omit-leaf-frame-pointer from build flags

On Tue, Jun 24, 2025 at 11:08 AM Davide Cavalca wrote: > > On 2025-06-24 12:06, Florian Weimer wrote: > > Sorry, I tried to make clear that this is regular C code compiled with > > the -mno-omit-leaf-frame-pointer flag, like the rest of the > > distribution. > > > > The only way in which glibc is

Re: Remove -mno-omit-leaf-frame-pointer from build flags

On Tue, Jun 24, 2025 at 07:48:56AM -, Indu Bhagat wrote: > 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. Bookmarked it, thanks! Rich. --

Re: Remove -mno-omit-leaf-frame-pointer from build flags

On 2025-06-22 16:17, Florian Weimer wrote: 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 fe

Re: Remove -mno-omit-leaf-frame-pointer from build flags

On 2025-06-24 12:06, Florian Weimer wrote: Sorry, I tried to make clear that this is regular C code compiled with the -mno-omit-leaf-frame-pointer flag, like the rest of the distribution. The only way in which glibc is special is that Wilco Dijkstra from Arm has recently optimized malloc to make

Re: Remove -mno-omit-leaf-frame-pointer from build flags

* Neal Gompa: > So my semi-naive interpretation of the problem here is that glibc is > special in that it doesn't provide any support for real-time tracing > or profiling. I'm not sure that justifies removing this flag globally, > as there are plenty of middleware stacks that do their own thing or

Re: Remove -mno-omit-leaf-frame-pointer from build flags

On Tue, Jun 24, 2025 at 12:17:18PM +0200, Neal Gompa wrote: > On Sun, Jun 22, 2025 at 11:43 AM Florian Weimer wrote: > > > > We currently use -mno-omit-leaf-frame-pointer on various architectures. > > I think we should remove it because it does not work as expected. > > > > Obviously, this does no

Re: Remove -mno-omit-leaf-frame-pointer from build flags

On Sun, Jun 22, 2025 at 11:43 AM Florian Weimer wrote: > > We currently use -mno-omit-leaf-frame-pointer on various architectures. > I think we should remove it because it does not work as expected. > > Obviously, this does not work for many glibc string functions because > they use hand-written a

Re: Remove -mno-omit-leaf-frame-pointer from build flags

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 > >

Re: Remove -mno-omit-leaf-frame-pointer from build flags

* Daniel P. Berrangé: >> 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? > > I recall the previous discussion around frame pointers was almost > exclusively around the m

Re: Remove -mno-omit-leaf-frame-pointer from build flags

On Sun, Jun 22, 2025 at 11:41:48AM +0200, Florian Weimer wrote: > We currently use -mno-omit-leaf-frame-pointer on various architectures. > I think we should remove it because it does not work as expected. I was confused for a minute as my eye tuned out the word '-leaf' in the arg above, so I mist

Re: Remove -mno-omit-leaf-frame-pointer from build flags

* Richard W. M. Jones: > 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 >> >

Re: Remove -mno-omit-leaf-frame-pointer from build flags

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 > > > Basically it pushes optiona