Pass1Parameter.c — take two, on Linux

Pass1Parameter-on-Linux takeaways

• Same C, completely different skeleton. Gone: sub rsp / add rsp, the shadow store, rsp-relative everything. Instead: push rbp · mov rbp, rsp · body · pop rbp · ret, with every variable addressed as [rbp−disp]. That two-instruction prologue is the highlighted pair in the course's Hello.c slide.
• Why push rbp at all? Because rbp is callee-saved in both ABIs — any function that wants to use it as a frame pointer must first preserve the caller's copy. The push is the save; the pop rbp in the epilogue is the matching restore. It has nothing to do with parameter passing.
• Two sanctioned trespasses, one per ABI. In 006 the MS callee wrote up, above its return address, into the caller's 0x20-byte shadow store. Today the SysV leaf callee wrote down, below rsp, into its 128-byte red zone. Neither is a bug — recognizing them is half of reading a listing.
• The RE pattern: see push rbp / mov rbp, rsp → you're in rbp-world: [rbp−X] = locals & homed params, [rbp] = saved rbp, [rbp+8] = return address, [rbp+10h] and up = stack-passed args (7th onward in SysV). A run of mov [rbp−X], edi/esi/edx… at the top is SysV parameter homing — count = arity, registers = order.
• endbr64 is noise. Intel CET landing pads — Ubuntu compiles everything with -fcf-protection, so every function entry gets one. Computationally a no-op; filter them out mentally.
• The full caller-/callee-saved team sheet (both ABIs, hover-able) lives in 006 — everything there still applies here.

The same function, two prologues

func() from Pass1Parameter.c, compiled by both planets. Red boxes = parameter homing, blue boxes = frame management:

• Anchor: MSVC measures everything from rsp (which moves exactly once, in the prologue); GCC -O0 freezes rbp at frame-birth and measures from it. Same memory, different ruler.
• Offsets change sign: MSVC's are positive from rsp; GCC's locals are negative from rbp, with the return address and any stack args at positive rbp offsets.
• Where a gets homed: MSVC writes upward into the caller's shadow store ([rsp+8] = above the return address); GCC writes downward into its own red zone ([rbp−14h] = below rsp). SysV has no shadow store; Windows has no red zone — each ABI's magic area is the other's illegal move.
• Arg register: ecx vs edi — arg1 differs per ABI. Return value: eax on both, the one thing everyone agrees on.
• Epilogue: MSVC undoes its arithmetic (add rsp, 18h); GCC just pop rbp — rsp never moved, so there's nothing to add back. When rsp has moved (non-leaf functions), GCC emits leave ≡ mov rsp, rbp + pop rbp — you'll meet it constantly.

The saved-rbp chain — a linked list of stack frames

Look at what the prologue pair builds, call after call: each frame's [rbp] slot holds the address of the previous frame's saved-rbp slot. A singly-linked list, threaded through the stack:

"When Does VS Use a Frame Pointer?"

Six steppers of MSVC output — 001 through 006, all at /Od — and rbp never once appeared. That's the default answer: it doesn't. Fixed-size frame → pure rsp-relative addressing, frame pointer omitted. The docs (the slide's two references) give the exceptions:

• A frame pointer becomes mandatory when the frame's size isn't a compile-time constant — alloca() / dynamic stack allocation, or dynamic stack alignment beyond 16 bytes. rsp wanders unpredictably then, so something stable must anchor the fixed part of the frame.
• When one is used, it doesn't have to be rbp — any nonvolatile register qualifies; the prolog example in the docs establishes R13 as the frame pointer.
• And it's typically parked mid-frame (e.g. lea r13, [rsp+80h] after the allocation), not at a saved-rbp slot — that way one-byte displacements (−80h…+7Fh) reach twice as much frame. No Linux-style saved-rbp chain is ever built; x64 Windows unwinds via UNWIND_INFO tables instead.

One more doc line that explains a 006-vs-007 difference you just watched:

Windows has no red zone. That's why 006's func had to sub rsp, 18h for a single int, while today's GCC func — same C! — allocated nothing and lived below rsp rent-free.

Two "maximum stack" diagrams — SysV vs Microsoft

The course's SysV maximum diagram (main → foo → bar), rebuilt next to the Microsoft one from the stack-usage doc. "(if any)" everywhere — a real frame uses only the rows it needs:

• Structural differences, in one breath: SysV homes into its own frame (or red zone); MS homes into the caller's shadow store. SysV spills at arg 7; MS at arg 5. SysV saves rbp at every -O0 frame; MS almost never.
• Both diagrams agree on the constants: stack grows down, call pushes 8 bytes, rsp is 16-byte aligned at every call — which is why misalignment crashes in library code (movaps!) are the classic hand-written-asm bug on both OSes.

The "As seen in Hello.c" slide — translated to Intel

The course showed it in AT&T (objdump's default). Same bytes, our syntax:

AT&T → Intel decoder ring (for watching the slides)

The mov %rsp,%rbp ↔ mov rbp, rsp flip is the one that bites: same three bytes (48 89 e5), opposite reading direction. When in doubt, remember what the prologue must do — copy rsp into rbp.

32-bit — where the frame pointer was born

Everything above is the modern era. In 32-bit x86 (cdecl, both Windows and Linux), there are no register arguments at all — every parameter is pushed onto the stack, right-to-left — and the ebp frame isn't a debug-build quirk, it's the culture:

The 32-bit convention zoo (spot them in the epilogue)

Epilogue tell: ret 8 → callee-cleaning (stdcall family, and the 8 = argument bytes → arity!); bare ret + add esp, N back at the call site → cdecl.

The whole map — four ABIs, one table

References — the "When Does VS Use a Frame Pointer?" slide

• [1] Microsoft stack diagram w/ optional frame pointer usage — x64 stack usage:
  https://docs.microsoft.com/en-us/cpp/build/stack-usage?view=msvc-160
• [2] x64 prolog and epilog:
  https://docs.microsoft.com/en-us/cpp/build/prolog-and-epilog?view=msvc-160