What registers does the System V AMD64 ABI require callee to preserve?

A strong answer

A strong candidate frames What registers does the System V AMD64 ABI require callee to preserve? around the exact memory layout, compiler semantics, and hardware execution model covered in Hardware Stack Architecture, Stack Frames, and the System V AMD64 ABI. Explain callee-saved registers (RBX, RBP, R12-R15) must be saved/restored by the callee.

To implement user-space coroutines, green threads, or fiber schedulers, you cannot rely on POSIX threads (pthread_create). A pthread requires:

1. A trip into the Linux kernel via clone() (~1,500 nanoseconds).
2. A default 8 MB virtual stack allocation.
3. Kernel Completely Fair Scheduler (CFS) preemption overhead.

To run millions of concurrent execution contexts on a single CPU core, you must take control of the CPU execution state directly in user space.

In a production interview, always connect the specification rule to its concrete runtime consequence: state what lives on the stack versus the heap or static storage segment, how the compiler or operating system validates alignments, lifetimes, and error codes, and what happens under adversarial or boundary inputs (such as zero-length buffers, integer overflow, concurrent mutation, or partial I/O). Backing your explanation with a small trace of register/memory state transitions immediately separates senior systems engineers from candidates who only memorized syntax.

What the interviewer is listening for

• Mastery of core invariant: Inspect stack frame growth, activation records, and stack pointer (%rsp) movements.
• Mastery of core invariant: Classify registers under the System V AMD64 ABI into caller-saved vs. callee-saved sets.
• Mastery of core invariant: Analyze the 128-byte x86-64 Red Zone and its implications for user-space context switches.
• Hardware and ABI awareness: Explaining how sizes, alignments, calling conventions, or kernel boundaries behave on real 64-bit targets rather than relying on implementation-defined assumptions.
• Defensive engineering: Naming the exact compiler flags (-Wall -Wextra -Werror), static analyzers, or runtime sanitizers (-fsanitize=address,undefined,thread) that verify correctness in CI.

Common mistakes

• Explaining only surface syntax without tracing the underlying memory addresses, ownership lifetime, or kernel/user-space state transitions.
• Assuming undefined behavior (such as signed overflow, uninitialized reads, strict-aliasing violations, or dangling pointers) will "just work" because it passed an unoptimized -O0 debug build.
• Ignoring return codes, partial reads/writes, alignment padding, or cleanup paths when an allocation or syscall fails midway through a function.