c++ - 底层段寄存器的线程本地实际使用

Question

我阅读了许多文章和 S/O 答案说(在 linux x86_64 上)FS(或某些变体中的 GS)引用了一个特定于线程的页表条目，然后它给出了一个指向可共享的实际数据的指针数组数据。当线程被交换时，所有的寄存器都被切换，因此线程基页会发生变化。线程变量通过名称访问，只需要 1 个额外的指针跃点，并且引用的值可以共享给其他线程。一切都好，说得通。
确实，如果您查看 __errno_location(void) 的代码，后面的函数errno ，你会发现类似的东西(这是来自 musl，但 gnu 并没有太大的不同):

static inline struct pthread *__pthread_self()
{
    struct pthread *self;
    __asm__ __volatile__ ("mov %%fs:0,%0" : "=r" (self) );
    return self;
}

来自 glibc:

=> 0x7ffff6efb4c0 <__errno_location>:   endbr64
   0x7ffff6efb4c4 <__errno_location+4>: mov    0x6add(%rip),%rax        # 0x7ffff6f01fa8
   0x7ffff6efb4cb <__errno_location+11>:        add    %fs:0x0,%rax
   0x7ffff6efb4d4 <__errno_location+20>:        retq

所以我的期望是 FS 的实际值会因每个线程而改变。例如。在调试器下，gdb: info reg或 p $fs ，我会看到 FS 的值在不同的线程中有所不同，但没有:ds、es、fs、gs 始终为零。
在我自己的代码中，我写了类似下面的内容并得到相同的结果 - FS 没有改变，但 TLV “有效”:

struct Segregs
{
    unsigned short int  cs, ss, ds, es, fs, gs;
    friend std::ostream& operator << (std::ostream& str, const Segregs& sr)
    {
        str << "[cs:" << sr.cs << ",ss:" << sr.ss << ",ds:" << sr.ds
            << ",es:" << sr.es << ",fs:" << sr.fs << ",gs:" << sr.gs << "]";
        return str;
    }
};

Segregs GetSegRegs()
{
    unsigned short int  r_cs, r_ss, r_ds, r_es, r_fs, r_gs;
    __asm__ __volatile__ ("mov %%cs,%0" : "=r" (r_cs) );
    __asm__ __volatile__ ("mov %%ss,%0" : "=r" (r_ss) );
    __asm__ __volatile__ ("mov %%ds,%0" : "=r" (r_ds) );
    __asm__ __volatile__ ("mov %%es,%0" : "=r" (r_es) );
    __asm__ __volatile__ ("mov %%fs,%0" : "=r" (r_fs) );
    __asm__ __volatile__ ("mov %%gs,%0" : "=r" (r_gs) );
    return {r_cs, r_ss, r_ds, r_es, r_fs, r_gs};
}

但是输出呢？

Main: Seg regs : [cs:51,ss:43,ds:0,es:0,fs:0,gs:0]
Main:    tls    @0x7ffff699307c=0
Main:    static @0x96996c=0
 Modified to 1234
Main:    tls    @0x7ffff699307c=1234
Main:    static @0x96996c=1234

 Async thread
[New Thread 0x7ffff695e700 (LWP 3335119)]
Thread: Seg regs : [cs:51,ss:43,ds:0,es:0,fs:0,gs:0]
Thread:  tls    @0x7ffff695e6fc=0
Thread:  static @0x96996c=1234

那么实际上还有其他事情发生吗？发生了什么额外的诡计，为什么要增加复杂性？
对于上下文，我正在尝试做一些“用 fork 时髦”的事情，所以我想知道血腥的细节。

Answer 1

在 64 位模式下，16 位 FS 和 GS 段寄存器的实际内容本质上是无关的。相反，CPU 中有单独的 64 位“FSBASE”和“GSBASE”寄存器，当你指定一个指令的 FS 段覆盖时，来自 FSBASE 寄存器的基地址被添加到操作数的有效地址中确定要访问的实际线性地址。
每个线程的内核上下文结构存储其 FSBASE 和 GSBASE 寄存器的拷贝，并且在每次上下文切换时适本地重新加载它们。
所以实际发生的是每个线程设置它的 FSBASE 寄存器指向它自己的线程本地存储。 (根据 CPU 功能和操作系统设计，这可能仅适用于特权代码，因此可能需要系统调用。)然后可以使用具有 FS 段覆盖的指令来访问线程中具有给定偏移量的对象 -本地存储块，如您所见。
另一方面，在 32 位模式下，FS 和 GS 中的值确实有意义；它们是段选择器，用于索引内核维护的描述符表。描述符表保存了实际的段信息，包括其基地址，您可以使用系统调用来要求内核修改它。每个线程都有自己的本地描述符表，因此您不一定会在 FS 中看到不同线程的不同选择器，但是来自不同线程的 FS-override 指令仍然会导致访问不同的线性地址。