Pass1Parameter.c — adding a single argument

Pass1Parameter.c takeaways

• Something very interesting is going on with the stack! The value passed in a register is still stored on the stack — doesn't that kind of defeat the speed benefit of passing arguments in registers? At /Od, honestly, yes: the compiler unconditionally homes every register parameter to memory so each variable has a stable address (which is exactly what a debugger wants). Optimized builds skip the store when they can — but the space is reserved either way.
• func() wrote above its own return address — legally. mov dword ptr [rsp+8], ecx lands in main's frame because the x64 convention makes the caller pre-allocate 0x20 bytes of shadow store that belong to the callee by contract.
• An RE pattern worth memorizing: a run of mov [rsp+8], ecx / mov [rsp+10h], edx / … at the very top of a function is the callee homing its parameters — the count tells you the arity, the registers tell you the order.
• After homing, a parameter behaves exactly like the locals from 002–005: plain rsp-relative displacements, no special instructions. The only novelty is whose frame the slot is in.

The experiment continues — TooManyParameters.c

One parameter told us "arg1 → ecx, homed at [rsp+8]". To find the full pattern, the course throws five parameters at the compiler and watches what falls out:

• A pattern emerges: args 1–4 go in rcx, rdx, r8, r9 and get homed into the caller's shadow store; arg5 has no register — main stores 55h straight to [rsp+20h], the first slot past the 0x20 shadow area, before the call.
• After func's sub rsp, 18h, all five params line up as plain displacements: a @ +20h, b @ +28h, c @ +30h, d @ +38h, e @ +40h — register-passed or stack-passed, they're indistinguishable in the body.
• main's frame math: shadow 0x20 + 8 for arg5 = 0x28 → rounded up to 0x30 in 16-byte chunks → + 8 alignment = sub rsp, 38h (that's the extra undef row at FDF8).
• The arithmetic: 0x11 + 0x22 − 0x33 + 0x44 − 0x55 = −0x11 → i = FFFFFFEF. (Also note this build homes and reads only the low dwords — r9d, not r9 — everything downstream is int math.)

Say hello to the Microsoft "shadow store"

Straight from the x64 calling convention docs:

And from the takeaway slide: "The callee has the responsibility of dumping the register parameters into their shadow space if needed" — the compiler reserves this space even if no function parameters are passed to another function. The whole contract, as one table (offsets are from the callee's rsp at entry, i.e. [rsp] = return address):

64-bit calling conventions — MS "x64" vs. System V "x86-64"

Two specs rule the planet. Everything above was the left one; gdb on Linux speaks the right one. The full documents (they really do have everything):

Same call, two register maps

The TooManyParameters signature again — colors follow the argument:

Read the columns and mind the trap: RCX = arg1 on Windows but arg4 on Linux; RDX = arg2 vs. arg3. Same register, different meaning — know the ABI before trusting a register. Spill-over args go on the stack, left-most at the lowest address ("pushed", though really mov, as we saw).

Who saves what — the full team sheet (hover a column)

Caller-save vs. callee-save — who owns the registers

Balance: every save is matched by a restore — the caller brackets the call site (save right before, restore right after), the callee brackets the whole function body (save in the prologue, restore in the epilogue). Anything pushed must get popped.

STACK FRAME TIME OUT — 001's mystery 0x28, finally solved

Back in CallASubroutine1, main() had no locals and passed no arguments, yet did sub rsp, 28h — and we had no explanation. Now we do. That frame was pure obligation: 0x20 of shadow store that main must allocate for any call ("even if the callee doesn't take that many parameters" — func took zero), plus 8 bytes of 16-byte-alignment padding.