Linux 从core信息中找到TLS信息

原文出处：http://blog.csdn.net/hnwyllmm/article/details/52164245

1. 背景
2. 依据
3. 测试
4. 总结

背景

我们在查core问题时，有时候需要查看某个TLS变量的值，但是GDB没有提供直接的命令，或者我不知道。这篇文字的目的，就是想办法从core文件中找出某个线程存放TLS变量的内容。

依据

Linux的glibc库创建线程时，使用mmap创建一块内存空间，作为此线程的栈空间。并将一个叫做struct pthread的数据结构放在栈的顶端(参考glibc代码allocate_stack@allocatestack.c)，而TLS的数据结构就在struct pthread中：

struct pthread{    // ...    struct pthread_key_data    {        uintptr_t seq;        void *data;    } specific_1stblock[PTHREAD_KEY_2NDLEVEL_SIZE];    struct pthread_key_data *specific[PTHREAD_KEY_1STLEVEL_SIZE];    // ...};
1
2
3
4
5
6
7
8
9
10
11
1
2
3
4
5
6
7
8
9
10
11

其中specific_1stblock数组是第一层的TLS变量，PTHREAD_KEY_2NDLEVEL_SIZE是一个宏定义，在glib2.20中的大小是32。如果TLS变量超过了这个值，就会使用specific来存储。从这里可以看出来，只要我们找到了specific_1stblock的位置，就能找到TLS变量的位置了。

根据上面的分析，我们需要先找到struct pthread的位置。先看一下struct pthread在栈中的位置：

      /* Place the thread descriptor at the end of the stack.  */#if TLS_TCB_AT_TP      pd = (struct pthread *) ((char *) mem + size - coloring) - 1;#elif TLS_DTV_AT_TP      pd = (struct pthread *) ((((uintptr_t) mem + size - coloring                    - __static_tls_size)                    & ~__static_tls_align_m1)                   - TLS_PRE_TCB_SIZE);#endif
1
2
3
4
5
6
7
8
9
1
2
3
4
5
6
7
8
9

pd的定义是struct pthread *pd;。代码中的mem是使用mmap创建的内存首地址。coloring根据宏定义COLORING_INCREMENT来决定是否是一个变化的值。在我看的代码版本和使用的操作系统(Redhat 6.5)安装的glibc中，都是0，也就是说coloring是一个常量0。这里还有两个宏定义条件，TLS_TCB_AT_TP和TLS_DTV_AT_TP，在glibc2.20，x86_64上使用的是TLS_TCB_AT_TP，因此pd相对于mem的偏移就是固定的大小sizeof(struct pthread)。

通过上面的描述，如果我们可以知道某个线程所在内存段，那么找到这个内存段的尾部，然后向前偏移sizeof(struct pthread)就可以找到struct pthread *的地址，进而找到specific_1stblock和specific的位置。

然而还有一个问题，就是怎么确定sizeof(struct pthread)的值？

虽然一个结构体在编译后的大小已经固定下来，但是看到glibc中复杂的定义，还有那么多宏定义限制，我就只能呵呵了。不过，我还有一招，就是直接从当前运行的一些程序中，确定sizeof(struct pthread)的大小。

glibc提供的很多函数中都会获取TLS信息，比如pthread_self。这个函数很短：

pthread_t__pthread_self (void){  return (pthread_t) THREAD_SELF;}
1
2
3
4
5
1
2
3
4
5

代码中THREAD_SELF的定义是

# define THREAD_SELF \  ({ struct pthread *__self;                              \     asm ("mov %%fs:%c1,%0" : "=r" (__self)                   \      : "i" (offsetof (struct pthread, header.self)));            \     __self;})
1
2
3
4
5
1
2
3
4
5

这个代码只是拿到fs段寄存器加上固定的偏移量的值。其实我本来想过直接用fs寄存器的值，可惜这个值不管在正在运行的程序中还是在core文件中，gdb都是看不到的。好吧，做了这么多白搭了。

不过幸运的是，gdb在调试正在执行的程序的时候，是可以直接执行函数的，我把pthread_self()函数的返回值拿出来，然后跟这个线程所在段的内存做对比，就可以知道struct pthread *相对于栈底的偏移量了。

费了九牛二虎之力拿到了sizeof(struct pthread)，回头看一看，才完成了任务的一半。还得知道specific_1stblock相对于struct pthread *的偏移量。不过还好，这个是比较容易做的，看看pthread_getspecific的汇编代码就一目了然了：

Dump of assembler code for function pthread_getspecific:   0x0000003bcd40c470 <+0>:     cmp    $0x1f,%edi   0x0000003bcd40c473 <+3>:     push   %rbx   0x0000003bcd40c474 <+4>:     ja     0x3bcd40c4ba <pthread_getspecific+74>   0x0000003bcd40c476 <+6>:     mov    %edi,%eax   0x0000003bcd40c478 <+8>:     shl    $0x4,%rax   0x0000003bcd40c47c <+12>:    mov    %fs:0x10,%rdx   0x0000003bcd40c485 <+21>:    lea    0x310(%rdx,%rax,1),%rdx   0x0000003bcd40c48d <+29>:    mov    0x8(%rdx),%rax   0x0000003bcd40c491 <+33>:    test   %rax,%rax   0x0000003bcd40c494 <+36>:    je     0x3bcd40c4ac <pthread_getspecific+60>   .....
1
2
3
4
5
6
7
8
9
10
11
12
1
2
3
4
5
6
7
8
9
10
11
12

对比一下glibc中的代码：

  struct pthread_key_data *data;  /* Special case access to the first 2nd-level block.  This is the     usual case.  */  if (__glibc_likely (key < PTHREAD_KEY_2NDLEVEL_SIZE))    data = &THREAD_SELF->specific_1stblock[key];  else
1
2
3
4
5
6
7
1
2
3
4
5
6
7

THREAD_SELF就是当前线程的struct pthread *。C代码跟汇编代码对比着看，就很容易找到specific_1stblock的偏移量。汇编中的edi寄存器就是传入的参数pthread_key_t key。 
mov %fs:0x10,%rdx这一行代码使用了fs寄存器，跟上面看到的pthread_self函数的方法一样，这就可以确定是获取struct pthread *的地址。 
那么接下来的一行lea 0x310(%rdx,%rax,1),%rdx自然就是获取specific_1stblock的值了。这一行中rdx寄存器存放struct pthread*，rax存放key * sizeof(struct pthread_key_data)，最后把rdx + (rax * 1) + 0x310的值放入了rdx中，很明显，0x310就是specific_1stblock的偏移量(0x310)。

到目前为止，已经准备好了所有获取TLS变量的条件，sizeof(struct pthread)和specific_1stblock的偏移量。下面就开始动手测试验证。

测试

写一个使用TLS的测试代码 
这个代码创建了一个线程变量和一个线程，创建出来的线程设置了线程变量的值。

#include <pthread.h>#include <unistd.h>pthread_key_t key;void *thread_func(void *arg){    pthread_setspecific(key, (const void *)0x12345678); // 设置一个特殊的值方便检测测试结果    sleep(100); // 睡眠一段时间用来生成core文件    return NULL;}int main(int argc, char **argv){    pthread_key_create(&key, NULL);    pthread_t tid;    pthread_create(&tid, NULL, thread_func, NULL);    pthread_join(tid, NULL);    return 0;}
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21

编译

g++ -lpthread test.cpp
1
1

默认生成a.out。直接执行，会在sleep中暂停一段时间，用gdb attach上去。 
执行info thread

(gdb) info thread  2 Thread 0x7f6cc2d15710 (LWP 15000)  0x0000003bcd0a6a8d in nanosleep () from /lib64/libc.so.6* 1 Thread 0x7f6cc2d17720 (LWP 14999)  0x0000003bcd40803d in pthread_join () from /lib64/libpthread.so.0(gdb) 
1
2
3
4
1
2
3
4

我们来看Thread 2，就是创建出来的线程。 
执行thread 2切换到线程2。 
执行call pthread_self()，结果却得到

(gdb) call pthread_self()$8 = -1026468080
1
2
1
2

改成十六进制打印

(gdb) p/x $8$9 = 0xc2d15710
1
2
1
2

明显还是不对，相当无语，gdb的call指令只打印了4个字节。不过稍微注意一下就发现了info thread输出的结果，有一个数据和这里一样：

2 Thread 0x7f6cc2d15710 (LWP 15000)  0x0000003bcd0a6a8d in nanosleep () from /lib64/libc.so.6
1
1

Thread后面的数字，就是pthread的地址，不过这个数据在调试core文件时并没有打印：

(gdb) info thread  2 Thread 14999  0x0000003bcd40803d in pthread_join () from /lib64/libpthread.so.0* 1 Thread 15000  0x0000003bcd0a6a8d in nanosleep () from /lib64/libc.so.6
1
2
3
1
2
3

虽然执行的结果与预期不符，但是还好拿到了pthread的地址。接下来找到这个线程所在的内存段，就是栈区间。进程的数据段信息可以从/proc/pid/maps文件中看到，其中pid是进程号。

这是我测试出来的进程中的内存信息：

7f6cc2315000-7f6cc2316000 ---p 00000000 00:00 0 7f6cc2316000-7f6cc2d1d000 rw-p 00000000 00:00 0 7fff4c321000-7fff4c337000 rw-p 00000000 00:00 0  [stack]7fff4c35a000-7fff4c35b000 r-xp 00000000 00:00 0  [vdso]
1
2
3
4
1
2
3
4

很明显，0x7f6cc2d15710属于这一段：

7f6cc2316000-7f6cc2d1d000 rw-p 00000000 00:00 0 
1
1

这就是线程2的栈空间，由于栈是从上往下增长的，那么栈底就是7f6cc2d1d000。它与0x7f6cc2d15710的距离是0x78f0。

在gdb中用gcore命令生成一个core文件，用gdb打开core文件验证测试，并找出TLS的值。

gdb a.out core
1
1

打印出core文件记录的程序内存段

(gdb) info filesSymbols from "/data01/usergrp/wangyl11/a.out".Local core dump file:        `/data01/usergrp/wangyl11/core.14999', file type elf64-x86-64.        0x0000000000400000 - 0x0000000000400000 is load1        0x0000000000600000 - 0x0000000000601000 is load2        0x00000000006d1000 - 0x00000000006f2000 is load3        .............................        0x0000003bcde83000 - 0x0000003bcde84000 is load24        0x00007f6cc2316000 - 0x00007f6cc2d1d000 is load25        0x00007fff4c321000 - 0x00007fff4c337000 is load26        0x00007fff4c35a000 - 0x00007fff4c35b000 is load27        0xffffffffff600000 - 0xffffffffff601000 is load28        ........
1
2
3
4
5
6
7
8
9
10
11
12
13
14
1
2
3
4
5
6
7
8
9
10
11
12
13
14

一大堆内存段，哪个才是自己要找的线程呢？

线程所处的空间是一个栈空间，那只要找到某个线程的栈上的变量或者其它信息，再根据这个信息就可以找到对应的内存段。有一个很容易查看的栈信息就是栈寄存器rsp。

看下线程的栈寄存器：

(gdb) thread 1[Switching to thread 1 (Thread 15000)]#0  0x0000003bcd0a6a8d in nanosleep () from /lib64/libc.so.6(gdb) info reg rsprsp            0x7f6cc2d14c90   0x7f6cc2d14c90
1
2
3
4
1
2
3
4

这样就找到了这个段：

0x00007f6cc2316000 - 0x00007f6cc2d1d000 is load25
1
1

这一段也是刚才看到的线程栈空间。拿栈底的地址就是 0x00007f6cc2d1d000，减去pthread偏移0x78f0就是 0x‭7F6CC2D15710‬，再加上specific_1stblock的偏移量0x310，得到‭0x7F6CC2D15A20‬。

最后一个，验证拿到地址正确性：

(gdb) x/2xg 0x7F6CC2D15A200x7f6cc2d15a20: 0x0000000000000001      0x0000000012345678
1
2
1
2

大功告成，上面的结果，第一个数字是seq，第二个是data(这两个是struct pthread_key_data的成员)。

虽然验证的core文件正好是拿执行程序生成的，不过就是再运行一次生成一个新的core文件，这个方法一样适用。

不过这也有受限的地方，最重要的原因是认为线程数据struct pthread就位于栈底，而栈在进程空间中是单独的一个内存段。如果这个栈空间是由用户创建线程时提供的，这个方法就可能不会适用。希望后面能找到更通用的方法，或许GDB会直接提供命令访问线程变量。

总结

1. 先找到struct pthread地址。可以通过gdb跟踪正在执行的程序，查找进程栈内存空间，找到距离栈底的距离；
2. 通过反汇编pthread_getspecific，找到specific_1stblock相对于struct pthread *的偏移量；
3. 在core文件中，通过栈寄存器rsp的地址，找到该线程所处内存段，根据上两步的信息，计算出specific_1stblock的地址，进而打印出TLS变量的值。

NOTE: 此方法受限于GLIBC自己创建的内存栈空间和Linux X86_64环境。