Hello, On Mon, 18 Nov 2024, Neal Gompa wrote:
It's not just about making accurate profiling easier, it's also about making it cheap. Frame pointers make it so you can sample at any point on a running system.
Just as well as without FP. At least with backtracers that aren't the most lazy imaginable implementation.
This is why the Go compiler has had frame pointers on by default for 6 years.
No, it's because the initial developers of the Go ecosystem were too lazy to implement DWARF, or equivalent, unwind info.
It's also why other operating systems have frame pointers on for non-x86_32. Linux is the outlier.
Why are you saying this? Windows x64 also doesn't require one.
In any case - I propose shipping all packages with debug info included since that greatly improves the profiling experience - even more so than by enabling frame-pointers. Bandwidth and disk is cheap these days.
Actually, DWARF based profiling isn't very good, which is why so few people do it. It's slow, it's memory intensive, thus the sampling capability is much poorer. Richard W.M. Jones did a decent comparison about this and the problems with DWARF profiling over leveraging frame pointers[2].
Then improve the DWARF backtracers (e.g. for pure backtraces it's usually not required to fully unwind stuff, which includes restoring all registers). Making everyone pay to cater for bad tooling for corner usecases is a bad tradeoff.
[2]: https://rwmj.wordpress.com/2023/02/14/frame-pointers-vs-dwarf-my-verdict/
So, let me see, because the kernel unwinder folks have some mysterious aversion to DWARF so that they (a) implement their own equivalent unwinder info, just less capable and (b) trace through frame pointers in userspace on their own, but do not do that for DWARF, everything is "bad" when not using frame pointers. (Of course it's bad with that implementation, to store the full stack up to a size into perf.data? I didn't realize how completely bollocks their approach to non-FP backtraces was.) So, then, how is that not fault of the kernel/perf, and should be worked around by enabling a frame pointer for everyone? Why is a blog post pointing out crazyness in tool A a reason to change tool B to the detriment of everyone? Tool A needs changing! I.e. I object with a passion! Ciao, Michael.