9 ms·

For the layman, what does this mean?

by herodoturtle 3y ago

supportengineer 3y ago
Exciting new failure modes
saagarjha 3y ago
Better stack traces for profiling tools when you don't have debugging symbols, or can't use them for whatever reason
im3w1l 3y ago
I was going to write a long essay about the relation between C and assembly but after thinking for a while, I think there is an easier way to explain it. Stack frames are basically a (single) linked list of information about the call stack. Every frame corresponds to one function call, and says where the local variables are stored, and where the function should return after it has finished. The head of this list is stored in a register (a scarce resource, superfast memory). So to use frame pointers, you have to spend one register, and also every function has to do some work to maintain the linked list. Two instructions worth of work when the function is enterred, and one when it exits. The alternative to doing this explicitly is to keep track of it all implicitly which is faster but a bit more complex.
brancz 3y ago
We wrote pretty extensively about what was needed to be able to profile things without frame pointers [1]. It's still possible at less than 1% overhead with the right set of technologies, but frame pointers unwinding is virtually free. [1] https://www.polarsignals.com/blog/posts/2022/11/29/dwarf-based-stack-walking-using-ebpf https://www.polarsignals.com/blog/posts/2022/11/29/dwarf-bas...
- mratsim 3y ago
  Intel VTune, Apple Instruments and perf have been able to profile without frame pointers.
  - brancz 3y ago
    A lot of profilers have, it’s literally what unwind information is for, but we did it in kernel therefore not the entire stack needs to be copied to user space so it’s way less overhead.
jcranmer 3y ago
There are two key effects of this decision. The first effect is that it makes one additional general-purpose integer register unavailable for use for code. x86-64 has 16 general-purpose registers, but one of these is the stack pointer and basically can't be used for any other purpose; this would add a second reserved register for the frame pointer. This effect may cause slowdowns if the 15th register was critical for performance. The second effect is on the ability to identify (and potentially unwind) the stack trace. With frame pointers, the pseudocode for computing a stack trace is essentially: do load return address, previous frame pointer from current frame pointer print return address move previous frame pointer into current frame pointer until current frame pointer is invalid Without frame pointers, the way you have to do this procedure is: while current address has corresponding entry in unwind table: parse unwind table entry to find a program to run run this program on the current frame to generate return address print return address move return address to current address It turns out that there is a full Turing-complete program described in the unwind tables to be able to generate a return address. This makes unwinding quite expensive, and also can create lots of security headaches if you want do something like unwind in the kernel (since the unwind table is arbitrary user code!). It can also be pretty unreliable at times, especially in cases where your program crashed due to stack smashing so that you have to expect that the data being randomly overwritten with garbage and thus horrifically inaccurate.
- nerpderp82 3y ago
  Since it hasn't been mentioned in this entire thread, frame pointers are required to get good high resolution flame graphs. https://www.brendangregg.com/flamegraphs.html https://www.brendangregg.com/flamegraphs.html With systems like Phlare/Pyroscope SRE can monitor application performance in a very granular way in realtime. https://grafana.com/blog/2023/03/15/pyroscope-grafana-phlare-join-for-oss-continuous-profiling/ https://grafana.com/blog/2023/03/15/pyroscope-grafana-phlare... https://github.com/grafana/pyroscope https://github.com/grafana/pyroscope
- mFixman 3y ago
  Could programs compiled in architectures with 16 general purpose registers fail in one with 15?
rwmj 3y ago
I wrote this about the change when Fedora did it about a year ago: https://rwmj.wordpress.com/2023/02/14/frame-pointers-vs-dwarf-my-verdict/ https://rwmj.wordpress.com/2023/02/14/frame-pointers-vs-dwar...

For the layman, what does this mean?

supportengineer 3y ago

Exciting new failure modes

saagarjha 3y ago

Better stack traces for profiling tools when you don't have debugging symbols, or can't use them for whatever reason

im3w1l 3y ago

I was going to write a long essay about the relation between C and assembly but after thinking for a while, I think there is an easier way to explain it. Stack frames are basically a (single) linked list of information about the call stack. Every frame corresponds to one function call, and says where the local variables are stored, and where the function should return after it has finished. The head of this list is stored in a register (a scarce resource, superfast memory). So to use frame pointers, you have to spend one register, and also every function has to do some work to maintain the linked list. Two instructions worth of work when the function is enterred, and one when it exits. The alternative to doing this explicitly is to keep track of it all implicitly which is faster but a bit more complex.

brancz 3y ago

We wrote pretty extensively about what was needed to be able to profile things without frame pointers [1]. It's still possible at less than 1% overhead with the right set of technologies, but frame pointers unwinding is virtually free. [1] https://www.polarsignals.com/blog/posts/2022/11/29/dwarf-based-stack-walking-using-ebpf https://www.polarsignals.com/blog/posts/2022/11/29/dwarf-bas...

mratsim 3y ago
Intel VTune, Apple Instruments and perf have been able to profile without frame pointers.
- brancz 3y ago
  A lot of profilers have, it’s literally what unwind information is for, but we did it in kernel therefore not the entire stack needs to be copied to user space so it’s way less overhead.

jcranmer 3y ago

There are two key effects of this decision. The first effect is that it makes one additional general-purpose integer register unavailable for use for code. x86-64 has 16 general-purpose registers, but one of these is the stack pointer and basically can't be used for any other purpose; this would add a second reserved register for the frame pointer. This effect may cause slowdowns if the 15th register was critical for performance. The second effect is on the ability to identify (and potentially unwind) the stack trace. With frame pointers, the pseudocode for computing a stack trace is essentially: do load return address, previous frame pointer from current frame pointer print return address move previous frame pointer into current frame pointer until current frame pointer is invalid Without frame pointers, the way you have to do this procedure is: while current address has corresponding entry in unwind table: parse unwind table entry to find a program to run run this program on the current frame to generate return address print return address move return address to current address It turns out that there is a full Turing-complete program described in the unwind tables to be able to generate a return address. This makes unwinding quite expensive, and also can create lots of security headaches if you want do something like unwind in the kernel (since the unwind table is arbitrary user code!). It can also be pretty unreliable at times, especially in cases where your program crashed due to stack smashing so that you have to expect that the data being randomly overwritten with garbage and thus horrifically inaccurate.

nerpderp82 3y ago
Since it hasn't been mentioned in this entire thread, frame pointers are required to get good high resolution flame graphs. https://www.brendangregg.com/flamegraphs.html https://www.brendangregg.com/flamegraphs.html With systems like Phlare/Pyroscope SRE can monitor application performance in a very granular way in realtime. https://grafana.com/blog/2023/03/15/pyroscope-grafana-phlare-join-for-oss-continuous-profiling/ https://grafana.com/blog/2023/03/15/pyroscope-grafana-phlare... https://github.com/grafana/pyroscope https://github.com/grafana/pyroscope
mFixman 3y ago
Could programs compiled in architectures with 16 general purpose registers fail in one with 15?

rwmj 3y ago

I wrote this about the change when Fedora did it about a year ago: https://rwmj.wordpress.com/2023/02/14/frame-pointers-vs-dwarf-my-verdict/ https://rwmj.wordpress.com/2023/02/14/frame-pointers-vs-dwar...