Prologue, epilogue, frame pointers

Every non-trivial function opens and closes with bookkeeping. Learn to skip it, and learn what its absence tells you.

The standard opening

"f":
        push    rbp             ; save caller's frame pointer
        mov     rbp, rsp        ; rbp now marks this frame
        sub     rsp, 32         ; allocate 32 bytes of locals
        ...
        leave                   ; = mov rsp, rbp ; pop rbp
        ret

rbp becomes a fixed landmark: locals sit at [rbp-8], [rbp-16], and arguments that arrived on the stack sit at [rbp+16] and up. Because rbp does not move while the function runs, every offset is constant — which is convenient for humans and for debuggers.

leave is a single instruction that undoes both steps.

The frame pointer is optional

The compiler knows exactly how far rsp has moved at every point, so it can address locals relative to rsp directly. rbp is redundant.

Omitting it buys two things: one extra general-purpose register (a real gain when you only have sixteen), and two fewer instructions per call. Historically that was measured at around 1%.

The cost is that you break cheap stack unwinding.

int add(int a, int b) {
    return a + b;
}

"add":
        lea     eax, [rdi+rsi]
        ret

Why this is a real engineering decision

A sampling profiler interrupts the program thousands of times per second and asks “where am I, and who called me?”. Answering the second half requires walking the stack.

With frame pointers that is trivial: each frame stores the previous rbp, so they form a linked list. Follow it. Cheap enough to do at high sampling rates.

Without them, the profiler needs DWARF unwind tables — extra data describing how to recover the caller at every instruction. These are large, sometimes absent in third-party or JIT-generated code, and expensive to interpret while sampling. The practical result is truncated stacks, stacks that stop at a library boundary, or plausible-looking nonsense.

This is why Fedora and Ubuntu re-enabled frame pointers by default, accepting roughly 1% throughput to make production profiling work. It is a genuine trade-off, and knowing which side you are on is useful: if you cannot profile production, you will lose far more than 1% to problems you never find.

ARM64

The shape is the same, the spelling differs:

        stp     x29, x30, [sp, #-16]!   ; save frame pointer AND link register
        mov     x29, sp
        ...
        ldp     x29, x30, [sp], #16
        ret

x29 is the frame pointer, x30 the link register. stp/ldp store and load a pair in one instruction, and the ! means pre-decrement — so allocation and saving happen together.

The tell for a leaf function is clean: if x30 is not saved, the function makes no calls. On x86 you have to infer that from the absence of call.

What you should now be able to say

• The prologue is push rbp / mov rbp, rsp / optional sub rsp, N; leave undoes it.
• The frame pointer is optional — the compiler can address locals off rsp.
• Omitting it gains a register and ~1%, and breaks cheap stack unwinding.
• Small leaf functions at -O2 typically have no prologue at all.
• ARM64 saves x29/x30 as a pair; unsaved x30 means leaf.

Next: 2.4 — Who saves what.