4 ms·
I would suggest not omitting the frame pointer. Fedora recently changed the default and it makes collecting stack traces vastly simpler, leading to better prof
by rwmj 4y ago
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-dwarf-my-verdict/ 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 http://oirase.annexia.org/tmp/2023-03-08-flamegraphs.mp4
- boulos 4y agoYeah, 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.
- fweimer 4y agoI 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.
- userbinator 4y agoThat was discussed at the time on HN: https://news.ycombinator.com/item?id=34632677 https://news.ycombinator.com/item?id=34632677 My comment on that article still stands: https://news.ycombinator.com/item?id=34660474 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.
- aktau 4y agoWalking the stack via frame pointers is also faster than some other methods (https://blog.felixge.de/reducing-gos-execution-tracer-overhead-with-frame-pointer-unwinding/ 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.
- xobs 4y agoYeah, 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 https://github.com/tock/tock/pull/1660
- fulafel 4y agoThis says the penalty is 10% on risc-v vs 2-3% on arm - anyone have background for why it's so?
- Someone 4y agoThere 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/Application-Level-Architecture/Instruction-Details/Alphabetical-list-of-instructions/STMDB---STMFD 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.
- ddevault 4y agoStrongly agreed. Unwinding with libunwind, i.e. DWARF, is way, way more complex. A simple linked list is much better for the common use-cases.