use of %fs segment register in x86_64 with -fstack-check

Maxim Blinov
Tue Mar 3 14:53:00 GMT 2020

Hi all,

I'm looking at some -fstack-check'ed code, and would appreciate it if
some gdb x86_64 gurus could double check my understanding of a trivial

here is the source:

#include <stdio.h>
#include <stdlib.h>
#include <stdint.h>

extern void foo(char *);

int main()
  char ch[8000];
  foo (ch);

  return 0;

void foo(char *ch) { }

And the compilation line:

$ gcc -O2 -fstack-check -o big-access big-access.c foo.c -fdump-rtl-final

And here is the gdb view (ignore the breakpoint and current insn caret):
B+ │0x555555554560 <main>           sub    $0x2f78,%rsp
   │0x555555554567 <main+7>         orq    $0x0,0xf58(%rsp)
   │0x555555554570 <main+16>        orq    $0x0,(%rsp)
   │0x555555554575 <main+21>        add    $0x1020,%rsp
   │0x55555555457c <main+28>        mov    %rsp,%rdi
   │0x55555555457f <main+31>        mov    %fs:0x28,%rax
  >│0x555555554588 <main+40>        mov    %rax,0x1f48(%rsp)
   │0x555555554590 <main+48>        xor    %eax,%eax
   │0x555555554592 <main+50>        callq  0x5555555546d0 <foo>
   │0x555555554597 <main+55>        mov    0x1f48(%rsp),%rdx
   │0x55555555459f <main+63>        xor    %fs:0x28,%rdx
   │0x5555555545a8 <main+72>        jne    0x5555555545b4 <main+84>
   │0x5555555545aa <main+74>        xor    %eax,%eax
   │0x5555555545ac <main+76>        add    $0x1f58,%rsp
   │0x5555555545b3 <main+83>        retq
   │0x5555555545b4 <main+84>        callq  0x555555554540 <__stack_chk_fail@plt>
   │0x5555555545b9                  nopl   0x0(%rax)

I would just like someone who knows their stuff to double check my

The "orq" at the start are purposefully causing a "dummy" load/store
event so the VMM can decide whether or not it is sane for us to have
used those pages for the stack, right?

Another question, is at address 0x55555555457f. I presume that
%fs:0x28 is a memory address that points to a sentinel value. We load
it into %rax, and then we store it in strategic locations in our stack
to serve as sentinel values. Before we leave, we check that the memory
location hasn't changed at 0x55555555459f. That implies, that the
memory location %fs:0x28 is pointing to a globally-used sentinel

But who sets %fs? Indeed what is the ABI usage of %fs in the context
of linux x86_64?
And why 0x28 offset?

Thankyou for reading,

More information about the Gdb mailing list