Ubuntu 24.04 LTS To Enable Frame Pointers By Default For Better Profiling/Debugging

[F.Ultra]

That sounds just like a frame pointer. I guess the only difference is that it's done on a case-by-case basis.

The extra calculation is done on a case by case basis but in general you always have the Stack Pointer (SP), the main difference is that that the Frame Pointer points to where the stack starts and the Stack Pointer points to where the stack ends so using one is by positive offsets and using the other is using negative offsets and if you have dynamic data then it is easier to use the frame pointer (if you put the dynamic ones last) since the Stack Pointer will increase with the dynamic amount.

And as DavidBrown mentions above the compiler will add a frame pointer if needed even if you use -fomit-frame-pointer

[Weasel]

So first fedora and now Ubuntu too.
At least ubuntu just downright says it's for ease of debugging. Whereas fedora tried to sell it with reasons like cloud computing with not easy to re-compile environments benefiting of this.

I find the move toward this "ease of debugging" just developer lazyness.

I maintain:
- Release builds should be build for performance. No extra debug aid.
- Debug builds contain the full-fancy-debug features (slower, bigger)
- Release with debug symbols. Those are trade-off builds where you gain debug information at the cost of a little performance and a lot of size. These builds are best to selectively send to people who have an issue to try and debug things. This mode also is often enough to develop software in. You still have much of the speed and much of the debug features.

What distributions provide should be release builds.

Edit.
Small correction. Thank for pointing it out spicfoo! My above remark w.r.t. fedora is apparently wrong. I swear there was some fedora debug-like flag added to packaged for their fedora server/cloud/coreos version but this wasn't it.

Amen.

[Weasel]

That sounds just like a frame pointer. I guess the only difference is that it's done on a case-by-case basis.

No, it uses the stack pointer directly.

There's zero reason to use frame pointer when you already have the stack pointer, when you could be using that frame pointer register for other things. Not to mention the overhead it takes to set it up upon function entry or return.

The only time it's actually needed is when the stack pointer has a non-fixed offset to the prior caller's frame, for example when aligning the stack, since then you don't know if it subtracted or not due to alignment.

[Weasel]

Anyway, more reasons to ditch Ubuntu, I already had enough but now I'm entirely sure of it.

[CommunityMember]

It does not only improve debugging but especially profiling. And profiling is nit only used by developers. Look at big server farms where they want to collect performance numbers.

It helps for stacktraces too.

One of the Gnome developers specifically mentioned that enabling frame pointers is a positive step forward for profiling for large applications such as Gnome (and who does not want their DE to be more responsive?)

[HadrienG]

Intel CPUs since Haswell can maintain LBR-based call stack specifically for the purposes of profiling, and it can be used using ol' trusty perf; similarly, recent AMDs can maintain something similar. If only the various cloud providers and VMs were to expose that hardware capability to their users...

LBR stack traces are great in theory but have two major issues in practice :

1. The relevant perf functionality has been broken on all AMD chips I could get my hands on ever since this manufacturer has been supposedly supported by perf, making LBR harder to use over time as more and more of the machines I have access to switch to AMD chips for obvious performance and energy efficiency reasons
2. 32 stack frames are definitely not enough for everybody. Any program that does recursion trivially blows past that, and while LBR stitching was a very cool workaround idea, I have yet to see the option do anything on a real profile...

[arteast]

LBR stack traces are great in theory but have two major issues in practice :

1. The relevant perf functionality has been broken on all AMD chips I could get my hands on ever since this manufacturer has been supposedly supported by perf, making LBR harder to use over time as more and more of the machines I have access to switch to AMD chips for obvious performance and energy efficiency reasons
2. 32 stack frames are definitely not enough for everybody. Any program that does recursion trivially blows past that, and while LBR stitching was a very cool workaround idea, I have yet to see the option do anything on a real profile...

I wonder if shadow stacks can be a no-cost solution then (in a potential world where shadow stacks are in use anyway for security purposes). It seems to be an ideal solution to gather the call stack since it IS the call stack, and (almost) call stack alone - no need to follow the frame pointer slist, just memcpy a block of memory and be done with it. IF profiler probe can read SSP (quickly), if the shadow stack itself is readable (again, quickly), and the markers that may be inserted into it can be easily dealt with.