Question

I would like an explanation for the values used with the .cfi_def_cfa_offset directives in assembly generated by GCC. I know vaguely that the .cfi directives are involved in call frames and stack unwinding, but I would like a more detailed explanation of why, for example, the values 16 and 8 are used in the assembly outputted by GCC in compiling the following C program on my 64-bit Ubuntu machine.

The C program:

#include <stdio.h>

int main(int argc, char** argv)
{
        printf("%d", 0);
        return 0;
}

I invoked GCC on the source file test.c as follows: gcc -S -O3 test.c. I know that -O3 enables nonstandard optimization, but I wanted to limit the size of the generated assembly for the sake of brevity.

The generated assembly:

        .file   "test.c"
        .section        .rodata.str1.1,"aMS",@progbits,1
.LC0:
        .string "%d"
        .text
        .p2align 4,,15
.globl main
        .type   main, @function
main:
.LFB22:
        .cfi_startproc
        subq    $8, %rsp
        .cfi_def_cfa_offset 16
        xorl    %edx, %edx
        movl    $.LC0, %esi
        movl    $1, %edi
        xorl    %eax, %eax
        call    __printf_chk
        xorl    %eax, %eax
        addq    $8, %rsp
        .cfi_def_cfa_offset 8
        ret
            .cfi_endproc
.LFE22:
        .size   main, .-main
        .ident  "GCC: (Ubuntu/Linaro 4.5.2-8ubuntu4) 4.5.2"
        .section        .note.GNU-stack,"",@progbits

Why are the values 16 and 8 used for the .cfi_def_cfa_offset directives in the generated assembly? Also, why is the number 22 used for the local function begin and function end labels?

Answer 1

As the DWARF spec says in section 6.4:

[…] The call frame is
identified by an address on the stack. We refer to this address as the Canonical Frame
Address or CFA. Typically, the CFA is defined to be the value of the stack pointer at the
call site in the previous frame (which may be different from its value on entry to the
current frame).

main() is called from somewhere else (in the libc C runtime support code), and, at the time the call instruction is executed, %rsp will point to the top of the stack (which is the lowest address – the stack grows downwards), whatever that may be (exactly what it is doesn’t matter here):

:                :                              ^
|    whatever    | <--- %rsp                    | increasing addresses
+----------------+                              |

The value of %rsp at this point is the “value of the stack pointer at the call site”, i.e. the CFA as defined by the spec.

As the call instruction is executed, it will push a 64-bit (8 byte) return address onto the stack:

:                :
|    whatever    | <--- CFA
+----------------+
| return address | <--- %rsp == CFA - 8
+----------------+

Now we are running the code at main, which executes subq $8, %rsp to reserve another 8 bytes of stack for itself:

:                :
|    whatever    | <--- CFA
+----------------+
| return address |
+----------------+
| reserved space | <--- %rsp == CFA - 16
+----------------+

The change of stack pointer is declared in the debugging information using the .cfi_def_cfa_offset directive, and you can see that the CFA is now at an offset of 16 bytes from the current stack pointer.

At the end of the function, the addq $8, %rsp instruction changes the stack pointer again, so another .cfi_def_cfa_offset directive is inserted to indicate that the CFA is now at an offset of only 8 bytes from the stack pointer.

(The number “22” in the labels is just an arbitrary value. The compiler will generate unique label names based on some implementation detail, such as its internal numbering of basic blocks.)