Hacker News Reader

Comment by rwmj | Hacker News Reader

I would suggest not omitting the frame pointer. Fedora recently changed the default and it makes collecting stack traces vastly simpler, leading to better profiling support (https://rwmj.wordpress.com/2023/02/14/frame-pointers-vs-dwar...)

Since then I gave a short (15 min) talk about producing and understanding flame graphs: http://oirase.annexia.org/tmp/2023-03-08-flamegraphs.mp4

View on HN

I still hope we can revert that once we have complete, CPU-verified backtraces. As a linked list, frame pointers are still somewhat slow. Just copying the hardware address stack should be quite a bit faster, and more importantly, the CPU will enforce that the addresses are correct.

Separate call and argument stacks?

Separate stack for return addresses (SHSTK, shadow stack).

Yeah, and I like I mentioned in the earlier comment, omitting the frame pointer reduces code size by 10% on RISC-V targets, which is huge when dealing with embedded flash: https://github.com/tock/tock/pull/1660

This says the penalty is 10% on risc-v vs 2-3% on arm - anyone have background for why it's so?

There can only be two answers:

- ARM frame pointer handling is more compact (relative to the non-frame pointer code) than that on RISC-V.

- ARM code does less frame pointer handling.

The first might be true because ARM has the stmdb instruction which (https://developer.arm.com/documentation/ddi0406/b/Applicatio...) stores multiple registers to consecutive memory locations using an address from a base register. The consecutive memory locations end just below this address, and the address of the first of those locations can optionally be written back to the base register.

So, code can save registers on the stack _and_ decrease the stack pointer in a single instruction.

The second might be true because, of the compilers/compiler settings used for those measurements the ARM one did more aggressive function inlining.

Yeah, mandating rbp on amd64 would have saved years of headache. There are still cases like tail calls that wouldn't work, but the vast majority of code doesn't need to care about dedicating a register to having usable backtraces.

Strongly agreed. Unwinding with libunwind, i.e. DWARF, is way, way more complex. A simple linked list is much better for the common use-cases.

That was discussed at the time on HN: https://news.ycombinator.com/item?id=34632677

My comment on that article still stands: https://news.ycombinator.com/item?id=34660474

tl;dr: don't make code generation worse for everyone else just to appease your one tiny use-case; fix your goddamn tools instead.

Walking the stack via frame pointers is also faster than some other methods (https://blog.felixge.de/reducing-gos-execution-tracer-overhe...), it appears. This benefits use cases like profilers and tracers. In big deployments, continuous (sampled) profiling and tracing are common, helping not only with continuous performance improvements in fleets but also helping to root cause outages. Reducing the cost of such infrastructure can pay off.

Reply on news.ycombinator.com