New blog post: The Return of the Frame Pointers (Fedora, Ubuntu) https://www.brendangregg.com/blog/2024-03-17/the-return-of-the-frame-pointers.html
The Return of the Frame Pointers

The Return of the Frame Pointers

@brendangregg As another data point: In the Wasmtime JIT for WebAssembly we've had frame pointers turned on unconditionally on x86-64 for several years, and started doing that for all architectures a couple years ago because we need to quickly capture a stack trace if the guest traps.

That said I'm confused by your suggestion that JITs can't produce DWARF, since Wasmtime does. That code is a regular source of bugs, and I'm not certain whether profilers can see the generated DWARF, but when it works, I believe at least gdb supports it.

That doesn't change your point that DWARF isn't a great choice for profiling, and for the same reasons we don't want to use DWARF for stack-walking.

But we've discussed that we may have to stop relying on frame pointers in the future to support WebAssembly exceptions proposals. We also don't currently do any inlining, so frame pointers can potentially be a significant hit if we have a ton of tiny leaf functions. So we still have open questions about what's the best thing for us to do.

@jamey @brendangregg Interesting - why are you outputting unwinding dwarf for JIT if you also have framepointers in the jit code? Is it needed for GDB unwinding to work?
@mstange @brendangregg We produce general-purpose DWARF (which register is this variable in, etc), which I believe happens to include enough for unwinding. I'm not super familiar with the details though, I could have some of this wrong.