I'm just studying how TLS (thread-local storage) is implemented on Linux systems. The document ELF Handling for Thread-Local Storage explains how a program's requirements for thread-local variables can be encoded in an ELF binary, and how the "runtime" should handle such binaries.
However, it's not clear to me whether in practice the "runtime" which sets up the TLS area(s) will be the Linux kernel (and its code for loading ELF binaries) or some initialization code in libc. Could someone explain briefly?
(Background: I'm trying to statically-link and run an application, but it segfaults on start. In gdb, I can see the segfaulting code is some init code from libc. It's trying to read a static variable using an address relative to GS, but GS is zero.)
Thread-local storage initialisation is part of the libc-provided start-up code. When statically linking, your linker should add the TLS initialisation to the start-up code linked into your program.
For example, glibc has __libc_setup_tls and _dl_tls_setup (among other, related things) in libc.a, which will be added to the initialisation code of your program if you link via, say, gcc -static. (For dynamically-linked programs the _dl_... functions are part of the ELF dynamic linker-loader, ld-linux.so, which isn't used to run a statically-linked program.)
Proper TLS initialisation in a statically-linked executable is, therefore, a result of collaboration between your C library (which provides the code) and your toolchain (which has to understand how to properly link in all the necessary start-up code).
The kernel's involvement in TLS initialisation is minor. (Basically, it just has to ensure that the .tdata section is available to libc for initialisation.) See ELF file TLS and LOAD program sections for details.