为什么独立的C hello程序在用作动态链接器时会崩溃

Question

以下程序：

#include <stdio.h>

int main(int argc, char *argv[])
{
  for (int j = 0; j < argc; j++)
    printf("%d: %s\n", j, argv[j]);
  return 0;
}

内置于静态链接的PIE中：

gcc -g -fpie main.c -static-pie -o ld.so

工作良好：

$ ./ld.so foo bar
0: ./ld.so
1: foo
2: bar

但是当我将该程序用作另一个程序的ELF解释器时：

$ gcc -g main.c -Wl,-I./ld.so -o a.out

它像这样崩溃：

gdb -q ./a.out
(gdb) run
Starting program: /tmp/a.out 

Program received signal SIGSEGV, Segmentation fault.
0x00007ffff7da84e2 in __ctype_init () at ctype-info.c:31
31    *bp = (const uint16_t *) _NL_CURRENT (LC_CTYPE, _NL_CTYPE_CLASS) + 128;
(gdb) bt
#0  0x00007ffff7da84e2 in __ctype_init () at ctype-info.c:31
#1  0x00007ffff7d9e3bf in __libc_init_first (argc=argc@entry=1, argv=argv@entry=0x7fffffffd728, envp=0x7fffffffd738) at ../csu/init-first.c:84
#2  0x00007ffff7d575cd in __libc_start_main (main=0x7ffff7d56e29 <main>, argc=1, argv=0x7fffffffd728, init=0x7ffff7d57ce0 <__libc_csu_init>, fini=0x7ffff7d57d70 <__libc_csu_fini>, rtld_fini=0x0, 
    stack_end=0x7fffffffd718) at ../csu/libc-start.c:244
#3  0x00007ffff7d56d6a in _start () at ../sysdeps/x86_64/start.S:120

这是为什么？

上面的所有地址都在./ld.so本身内，因此它在自己的初始化过程中会崩溃。事实上，自a.out退出以来，控制权永远不会达到ld.so。

Answer 1

调试时间比我预期的要长一些。

崩溃发生在：

Dump of assembler code for function __ctype_init:
   0x00007ffff7da84d0 <+0>:     mov    $0xffffffffffffffa0,%rax
   0x00007ffff7da84d7 <+7>:     mov    $0xfffffffffffffff0,%rcx
   0x00007ffff7da84de <+14>:    mov    %fs:(%rax),%rax
=> 0x00007ffff7da84e2 <+18>:    mov    (%rax),%rax
   0x00007ffff7da84e5 <+21>:    mov    0x40(%rax),%rsi

与$rax == 0。当ld.so本身经历这段代码时，$rax显然是非NULL的。在TLS设置期间显然出现了问题，但是什么？

事实证明，GLIBC从辅助矢量中的_dl_phdr初始化其AT_PHDR，然后遍历所有Phdrs以寻找具有PT_TLS类型的TLS。

如果没有，则GLIBC假定不需要设置ld.so。

当Phdr直接运行时，内核提供的辅助矢量指向ld.so，PT_TLS，ld.so存在，一切正常。

但是当a.out作为Phdr的翻译间接运行时，辅助矢量指向a.out的ld.sos（而不是a.out - 这是设计的）。由于PT_TLS没有任何线程局部变量，因此它也没有ELF段。

结论：目前不可能使用-static-pie和GLIBC构建int main() { return 0; }解释器，除非人们非常小心地避免线程局部存储。目前看来，避免线程本地存储似乎也不是一个选择：尽管GLIBC没有使用任何东西，但是一个简单的TLS仍然有一个qazxswpoi段。