linux - 共享库如何找到 GOT 部分？

Question

当我在阅读时 http://eli.thegreenplace.net/2011/11/03/position-independent-code-pic-in-shared-libraries/#id1问题来了:

PIC 共享库加载到进程虚拟地址空间某处后如何知道如何引用外部变量？

这里是有问题的共享库的代码:

#include <stdio.h>

extern long var;

void
shara_func(void)
{
        printf("%ld\n", var);
}

生成目标代码，然后共享对象(库):

gcc -fPIC -c lib1.c                    # produce PIC lib1.o
gcc -fPIC -shared lib1.o -o liblib1.so # produce PIC shared library

反汇编共享库中的shara_func:

objdump -d liblib1.so
 ...
 00000000000006d0 <shara_func>:
 6d0:   55                      push   %rbp
 6d1:   48 89 e5                mov    %rsp,%rbp
 6d4:   48 8b 05 fd 08 20 00    mov    0x2008fd(%rip),%rax        # 200fd8 <_DYNAMIC+0x1c8>
 6db:   48 8b 00                mov    (%rax),%rax
 6de:   48 89 c6                mov    %rax,%rsi
 6e1:   48 8d 3d 19 00 00 00    lea    0x19(%rip),%rdi        # 701 <_fini+0x9>
 6e8:   b8 00 00 00 00          mov    $0x0,%eax
 6ed:   e8 be fe ff ff          callq  5b0 <printf@plt>
 6f2:   90                      nop
 6f3:   5d                      pop    %rbp
 6f4:   c3                      retq   
...

我看到 0x6d4 地址处的指令将一些相对于 PC 的地址移动到 rax，我想那是 GOT 中的条目, GOT 在运行时从 PC 相对引用以获取外部变量 var 的地址(它在运行时根据 var 的加载位置进行解析)。然后在0x6db处执行指令后，我们将外部变量的实际内容放在rax中，然后将值从rax移动到rsi - 在寄存器中传递的第二个函数参数。

我以为进程内存中只有一个GOT，然而，看到图书馆引用 GOT？当共享库(PIC 库)不知道它将加载到进程内存中的哪个位置时，它如何知道进程 GOT 的偏移量？或者每个共享库都有自己的 GOT 加载她？如果您能澄清我的困惑，我将非常高兴。

Answer 1

I was thinking that there is only one GOT in process memory, however, see that library references GOT?

我们清楚地看到 .got 部分是库的一部分。使用 readelf 我们可以找到库的部分以及它们是如何加载的:​​

readelf -e liblib1.so
...
Section Headers:
  [21] .got              PROGBITS         0000000000200fd0  00000fd0
       0000000000000030  0000000000000008  WA       0     0     8
...

Program Headers:
  Type           Offset             VirtAddr           PhysAddr
                 FileSiz            MemSiz              Flags  Align
  LOAD           0x0000000000000000 0x0000000000000000 0x0000000000000000
                 0x000000000000078c 0x000000000000078c  R E    200000
  LOAD           0x0000000000000df8 0x0000000000200df8 0x0000000000200df8
                 0x0000000000000230 0x0000000000000238  RW     200000
...
 Section to Segment mapping:
  Segment Sections...
   00     ... .init .plt .plt.got .text .fini .rodata .eh_frame_hdr .eh_frame 
   01     .init_array .fini_array .jcr .dynamic .got .got.plt .data .bss 
   02     .dynamic 

所以，有 .got 部分，但是 runtime linker ld-linux.so.2 (注册为动态 ELF 的解释器)不加载部分；它按照 LOAD 类型的程序头描述的方式加载段。 .got 是带有 RW 标志的段 01 LOAD 的一部分。其他库将拥有自己的 GOT(考虑从类似源编译 liblib2.so，它不会知道任何关于 liblib1.so 的信息，并且将拥有自己的 GOT)；所以它只对图书馆来说是“全局”的；但不是加载后内存中的整个程序图像。

How shared library knows offset to process's GOT when it(PIC library) does not know where in process memory it would be loaded?

这是由静态链接器完成的，它需要几个 ELF 对象并将它们全部组合到一个库中。链接器将生成 .got 部分并将其放置到与库代码(pc-relative，rip-relative)具有已知偏移量的某个位置。它将指令写入程序头，因此相对地址是已知的，它是访问自己的GOT唯一需要的地址。

当 objdump 与 -r/-R 标志一起使用时，它将打印有关重定位(静态/动态)的信息，记录在ELF 文件或库；它可以与 -d 标志结合使用。 lib1.o 对象在这里重定位；没有已知的 GOT 偏移量，mov 全部为零:

$ objdump -dr lib1.o 
lib1.o:     file format elf64-x86-64

Disassembly of section .text:

0000000000000000 <shara_func>:
   0:   55                      push   %rbp
   1:   48 89 e5                mov    %rsp,%rbp
   4:   48 8b 05 00 00 00 00    mov    0x0(%rip),%rax        # b <shara_func+0xb>
            7: R_X86_64_REX_GOTPCRELX   var-0x4
   b:   48 8b 00                mov    (%rax),%rax
   e:   48 89 c6                mov    %rax,%rsi

在库文件中，它被 gcc -shared 转换为相对地址(它在内部调用 ld 变体 collect2):

$ objdump -d liblib1.so 

liblib1.so:     file format elf64-x86-64

00000000000006d0 <shara_func>:
 6d0:   55                      push   %rbp
 6d1:   48 89 e5                mov    %rsp,%rbp
 6d4:   48 8b 05 fd 08 20 00    mov    0x2008fd(%rip),%rax        # 200fd8 <_DYNAMIC+0x1c8>

最后，动态重定位到 GOT 以将 var 的实际地址放在这里(由 rtld - ld-linux.so.2 完成):

$ objdump -R liblib1.so 

liblib1.so:     file format elf64-x86-64

DYNAMIC RELOCATION RECORDS
OFFSET           TYPE              VALUE 
...
0000000000200fd8 R_X86_64_GLOB_DAT  var

让我们使用您的库，添加带有定义的可执行文件，编译它并在启用 rtld 调试的情况下运行:

$ cat main.c 
long var;
int main(){
    shara_func();
    return 0;
}
$ gcc main.c -llib1 -L. -o main -Wl,-rpath=`pwd`
$ LD_DEBUG=all ./main 2>&1 |less
...
   311:     symbol=var;  lookup in file=./main [0]
   311:     binding file /test3/liblib1.so [0] to ./main [0]: normal symbol `var'

因此，链接器能够将 var 的重定位绑定(bind)到定义它的“主”ELF 文件:

$ gdb -q ./main 
Reading symbols from ./main...(no debugging symbols found)...done.
(gdb) b main
Breakpoint 1 at 0x4006da
(gdb) r
Starting program: /test3/main 

Breakpoint 1, 0x00000000004006da in main ()
(gdb) disassemble shara_func
Dump of assembler code for function shara_func:
   0x00007ffff7bd56d0 <+0>: push   %rbp
   0x00007ffff7bd56d1 <+1>: mov    %rsp,%rbp
   0x00007ffff7bd56d4 <+4>: mov    0x2008fd(%rip),%rax        # 0x7ffff7dd5fd8
   0x00007ffff7bd56db <+11>:    mov    (%rax),%rax
   0x00007ffff7bd56de <+14>:    mov    %rax,%rsi

您的函数中的 mov 没有变化。 func+4之后的rax是0x601040，根据/proc/$pid/maps是./main的第三次映射:

00601000-00602000 rw-p 00001000 08:07 6691394                            /test3/main

它是在这个程序头之后从 main 加载的 (readelf -e ./main)

LOAD           0x0000000000000df0 0x0000000000600df0 0x0000000000600df0
               0x0000000000000248 0x0000000000000258  RW     200000

它是 .bss 部分的一部分:

 [26] .bss              NOBITS           0000000000601038  00001038
      0000000000000010  0000000000000000  WA       0     0     8

单步执行到 func+11 后，我们可以检查 GOT 中的值:

(gdb) b shara_func
(gdb) r
(gdb) si
0x00007ffff7bd56db in shara_func () from /test3/liblib1.so
1: x/i $pc
=> 0x7ffff7bd56db <shara_func+11>:  mov    (%rax),%rax
(gdb) p $rip+0x2008fd
$6 = (void (*)()) 0x7ffff7dd5fd8
(gdb) x/2x 0x7ffff7dd5fd8
0x7ffff7dd5fd8: 0x00601040  0x00000000

谁向这个 GOT 条目写入了正确的值？

(gdb) watch *0x7ffff7dd5fd8
Hardware watchpoint 2: *0x7ffff7dd5fd8
(gdb) r
The program being debugged has been started already.
Start it from the beginning? (y or n) y
Starting program: /test3/main 

Hardware watchpoint 2: *0x7ffff7dd5fd8

Old value = <unreadable>
New value = 6295616
0x00007ffff7de36bf in elf_machine_rela (..) at ../sysdeps/x86_64/dl-machine.h:435
(gdb) bt
#0  0x00007ffff7de36bf in elf_machine_rela (...) at ../sysdeps/x86_64/dl-machine.h:435
#1  elf_dynamic_do_Rela (...) at do-rel.h:137
#2  _dl_relocate_object (...) at dl-reloc.c:258
#3  0x00007ffff7ddaf5b in dl_main (...)        at rtld.c:2072
#4  0x00007ffff7df0462 in _dl_sysdep_start (start_argptr=start_argptr@entry=0x7fffffffde20, 
    dl_main=dl_main@entry=0x7ffff7dd89a0 <dl_main>) at ../elf/dl-sysdep.c:249
#5  0x00007ffff7ddbe7a in _dl_start_final (arg=0x7fffffffde20) at rtld.c:307
#6  _dl_start (arg=0x7fffffffde20) at rtld.c:413
#7  0x00007ffff7dd7cc8 in _start () from /lib64/ld-linux-x86-64.so.2

(gdb) x/2x 0x7ffff7dd5fd8
0x7ffff7dd5fd8: 0x00601040  0x00000000

glibc 的运行时链接器 (rtld.c)，就在调用 main 之前 - 这是源代码(有点不同的版本)- http://code.metager.de/source/xref/gnu/glibc/sysdeps/x86_64/dl-machine.h

329 case R_X86_64_GLOB_DAT:
330 case R_X86_64_JUMP_SLOT:
331   *reloc_addr = value + reloc->r_addend;
332   break;

通过反向步进，我们可以获得代码历史和旧值 = 0:

(gdb) b _dl_relocate_object 
(gdb) r
(gdb) dis 3
(gdb) target record-full
(gdb) c
(gdb) disp/i $pc
(gdb) rsi
(gdb) rsi
(gdb) rsi
(gdb) x/2x 0x7ffff7dd5fd8
0x7ffff7dd5fd8: 0x00000000  0x00000000


=> 0x7ffff7de36b8 <_dl_relocate_object+1560>:   add    0x10(%rbx),%rax
=> 0x7ffff7de36bc <_dl_relocate_object+1564>:   mov    %rax,(%r10)
=> 0x7ffff7de36bf <_dl_relocate_object+1567>:   nop