[在运行时加载动态库会产生不一致和意外的结果，缺少符号和空PLT条目。为什么？

问题描述 投票：1回答：1

我一直在与这个问题作斗争很长时间了，但是我一直无法找到解决方案甚至是解释。非常抱歉，如果问题很长，请允许我，我只是想100％明确地说，希望比我更有经验的人能够解决。

我将所有代码片段的C语法高亮显示，因为即使不是很正确，它也会使它们更加清晰。

我想做什么

我有一个C程序，该程序使用动态库（libzip）中的某些功能。这里将其归结为一个最小的可重现示例（它基本上不执行任何操作，但是效果很好）：

#include <zip.h>

int main(void) {
    int err;
    zip_t *myzip;

    myzip = zip_open("myzip.zip", ZIP_CREATE | ZIP_TRUNCATE, &err);
    if (myzip == NULL)
        return 1;

    zip_close(myzip);

    return 0;
}

通常，要编译它，我只会做：

gcc -c prog.c
gcc -o prog prog.o -lzip

这将按预期创建需要运行libzip的ELF：

$ ldd prog
linux-vdso.so.1 (0x00007ffdafb53000)
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f81eedc7000)
/lib64/ld-linux-x86-64.so.2 (0x00007f81ef780000)
libzip.so.4 => /usr/lib/x86_64-linux-gnu/libzip.so.4 (0x00007f81ef166000)
libz.so.1 => /lib/x86_64-linux-gnu/libz.so.1 (0x00007f81eebad000)

（[libz只是对libzip的依赖]

我确实想要做的是使用dlopen()自己加载库。很简单的任务，不是吗？好吧，或者至少我以为。

要实现这一点，我只需要调用dlopen并让加载程序完成其工作：

#include <zip.h>
#include <dlfcn.h>

int main(void) {
    void *lib;
    int err;
    zip_t *myzip;

    lib = dlopen("libzip.so", RTLD_LAZY | RTLD_GLOBAL);
    if (lib == NULL)
        return 1;

    myzip = zip_open("myzip.zip", ZIP_CREATE | ZIP_TRUNCATE, &err);
    if (myzip == NULL)
        return 1;

    zip_close(myzip);

    return 0;
}

当然，由于我想手动自己加载库，因此这次我不会链接它：

# Create prog.o
gcc -c prog.c

# Do a dry-run just to make sure all symbols are resolved
gcc -o /dev/null prog.o -ldl -lzip

# Now recompile only with libdl
gcc -o prog prog.o -ldl -Wl,--unresolved-symbols=ignore-in-object-files

标志--unresolved-symbols=ignore-in-object-files告诉ld不必担心我的prog.o在链接时有未解析的符号（我想在运行时照顾自己）。

问题

以上Should Just Work™，的确确实如此……但是我有两台机器，作为书呆子书呆子，我只是在想：“好吧，最好确保并在两个版本上编译他们”。

第一台机器

x86-64，Linux 4.9，Debian 9，gcc 6.3.0，ld 2.28。在这里一切都会按预期进行。

我可以清楚地看到那里有符号：

$ readelf --dyn-syms prog

Symbol table '.dynsym' contains 15 entries:
   Num:    Value          Size Type    Bind   Vis      Ndx Name
     0: 0000000000000000     0 NOTYPE  LOCAL  DEFAULT  UND
     1: 0000000000000000     0 NOTYPE  WEAK   DEFAULT  UND _ITM_deregisterTMCloneTab
     2: 0000000000000000     0 FUNC    GLOBAL DEFAULT  UND __libc_start_main@GLIBC_2.2.5 (2)
     3: 0000000000000000     0 NOTYPE  WEAK   DEFAULT  UND __gmon_start__
===> 4: 0000000000000000     0 FUNC    GLOBAL DEFAULT  UND zip_close
     5: 0000000000000000     0 FUNC    GLOBAL DEFAULT  UND dlopen@GLIBC_2.2.5 (3)
===> 6: 0000000000000000     0 FUNC    GLOBAL DEFAULT  UND zip_open
     7: 0000000000000000     0 NOTYPE  WEAK   DEFAULT  UND _Jv_RegisterClasses
     8: 0000000000000000     0 NOTYPE  WEAK   DEFAULT  UND _ITM_registerTMCloneTable
     9: 0000000000000000     0 FUNC    WEAK   DEFAULT  UND __cxa_finalize@GLIBC_2.2.5 (2)
    10: 0000000000201040     0 NOTYPE  GLOBAL DEFAULT   25 _edata
    11: 0000000000201048     0 NOTYPE  GLOBAL DEFAULT   26 _end
    12: 0000000000201040     0 NOTYPE  GLOBAL DEFAULT   26 __bss_start
    13: 00000000000006a0     0 FUNC    GLOBAL DEFAULT   11 _init
    14: 0000000000000924     0 FUNC    GLOBAL DEFAULT   15 _fini

PLT条目也如预期的那样，看起来不错：

$ objdump -j .plt -M intel -d prog

Disassembly of section .plt:

00000000000006c0 <.plt>:
 6c0:   ff 35 42 09 20 00       push   QWORD PTR [rip+0x200942]        # 201008 <_GLOBAL_OFFSET_TABLE_+0x8>
 6c6:   ff 25 44 09 20 00       jmp    QWORD PTR [rip+0x200944]        # 201010 <_GLOBAL_OFFSET_TABLE_+0x10>
 6cc:   0f 1f 40 00             nop    DWORD PTR [rax+0x0]

00000000000006d0 <zip_close@plt>:
 6d0:   ff 25 42 09 20 00       jmp    QWORD PTR [rip+0x200942]        # 201018 <zip_close>
 6d6:   68 00 00 00 00          push   0x0
 6db:   e9 e0 ff ff ff          jmp    6c0 <.plt>

00000000000006e0 <dlopen@plt>:
 6e0:   ff 25 3a 09 20 00       jmp    QWORD PTR [rip+0x20093a]        # 201020 <dlopen@GLIBC_2.2.5>
 6e6:   68 01 00 00 00          push   0x1
 6eb:   e9 d0 ff ff ff          jmp    6c0 <.plt>

00000000000006f0 <zip_open@plt>:
 6f0:   ff 25 32 09 20 00       jmp    QWORD PTR [rip+0x200932]        # 201028 <zip_open>
 6f6:   68 02 00 00 00          push   0x2
 6fb:   e9 c0 ff ff ff          jmp    6c0 <.plt>

程序运行没有问题：

$ ./prog
$ echo $?
0

即使使用调试器查看它的内部，我也可以清楚地看到符号像任何普通的动态符号一样都能正确解析：

0x55555555479b <main+43>                       lea    rax, [rbp - 0x14]
0x55555555479f <main+47>                       mov    rdx, rax
0x5555555547a2 <main+50>                       mov    esi, 9
0x5555555547a7 <main+55>                       lea    rdi, [rip + 0xc0] <0x7ffff7ffd948>
0x5555555547ae <main+62>                       call   zip_open@plt <0x555555554620>
 |
 v ### PLT entry:
0x555555554620 <zip_open@plt>                  jmp    qword ptr [rip + 0x200a02] <0x555555755028>
 |
 v 
0x555555554626 <zip_open@plt+6>                push   2
0x55555555462b <zip_open@plt+11>               jmp    0x5555555545f0
 |
 v ### PLT stub:
0x5555555545f0                                 push   qword ptr [rip + 0x200a12] <0x555555755008>
0x5555555545f6                                 jmp    qword ptr [rip + 0x200a14] <0x7ffff7def0d0>
 |
 v ### Symbol gets correctly resolved
0x7ffff7def0d0 <_dl_runtime_resolve_fxsave>    push   rbx
0x7ffff7def0d1 <_dl_runtime_resolve_fxsave+1>  mov    rbx, rsp
0x7ffff7def0d4 <_dl_runtime_resolve_fxsave+4>  and    rsp, 0xfffffffffffffff0
0x7ffff7def0d8 <_dl_runtime_resolve_fxsave+8>  sub    rsp, 0x240

第二台机器

x86-64，Linux 4.15，Ubuntu 18.04，gcc 7.4，ld 2.30。在这里，确实很奇怪的事情正在发生>>。

编译不会产生任何警告或错误，但是

我看不到符号：
$ readelf --dyn-syms prog

Symbol table '.dynsym' contains 7 entries:
   Num:    Value          Size Type    Bind   Vis      Ndx Name
     0: 0000000000000000     0 NOTYPE  LOCAL  DEFAULT  UND
     1: 0000000000000000     0 NOTYPE  WEAK   DEFAULT  UND _ITM_deregisterTMCloneTab
     2: 0000000000000000     0 FUNC    GLOBAL DEFAULT  UND __libc_start_main@GLIBC_2.2.5 (2)
     3: 0000000000000000     0 NOTYPE  WEAK   DEFAULT  UND __gmon_start__
     4: 0000000000000000     0 FUNC    GLOBAL DEFAULT  UND dlopen@GLIBC_2.2.5 (3)
     5: 0000000000000000     0 NOTYPE  WEAK   DEFAULT  UND _ITM_registerTMCloneTable
     6: 0000000000000000     0 FUNC    WEAK   DEFAULT  UND __cxa_finalize@GLIBC_2.2.5 (2)

PLT条目在那里
，但是它们用零填充，甚至没有被objdump识别：
$ objdump -j .plt -M intel -d prog

Disassembly of section .plt:

0000000000000560 <.plt>:
 560:   ff 35 4a 0a 20 00       push   QWORD PTR [rip+0x200a4a]        # 200fb0 <_GLOBAL_OFFSET_TABLE_+0x8>
 566:   ff 25 4c 0a 20 00       jmp    QWORD PTR [rip+0x200a4c]        # 200fb8 <_GLOBAL_OFFSET_TABLE_+0x10>
 56c:   0f 1f 40 00             nop    DWORD PTR [rax+0x0]
    ...

#   ^^^
# Here, these three dots are actually hiding another 0x10+ bytes filled of 0x0
# zip_close@plt should be here instead...

0000000000000580 <dlopen@plt>:
 580:   ff 25 42 0a 20 00       jmp    QWORD PTR [rip+0x200a42]        # 200fc8 <dlopen@GLIBC_2.2.5>
 586:   68 00 00 00 00          push   0x0
 58b:   e9 d0 ff ff ff          jmp    560 <.plt>
    ...

#   ^^^
# Here, these three dots are actually hiding another 0x10+ bytes filled of 0x0
# zip_open@plt should be here instead...

[程序运行时，dlopen()可以正常工作并将libzip加载到内存中，但是当zip_open()被调用时，它仅会产生分段错误：
$ ./prog
Segmentation fault (code dumped)

与调试器一起查看，问题更加明显（以防万一，这个问题还不够明显）。填充有零的PLT条目最终会解码为解引用add的一堆rax指令，该指令包含无效地址并导致程序段错误和死亡：
0x5555555546e5 <main+43>               lea    rax, [rbp - 0x14]
0x5555555546e9 <main+47>               mov    rdx, rax
0x5555555546ec <main+50>               mov    esi, 9
0x5555555546f1 <main+55>               lea    rdi, [rip + 0xc6]
0x5555555546f8 <main+62>               call   dlopen@plt+16 <0x555555554590>
 |
 v ### Broken PLT enrty (all 0x0, will cause a segfault):
0x555555554590 <dlopen@plt+16>         add    byte ptr [rax], al
0x555555554592 <dlopen@plt+18>         add    byte ptr [rax], al
0x555555554594 <dlopen@plt+20>         add    byte ptr [rax], al
0x555555554596 <dlopen@plt+22>         add    byte ptr [rax], al
0x555555554598 <dlopen@plt+24>         add    byte ptr [rax], al
0x55555555459a <dlopen@plt+26>         add    byte ptr [rax], al
0x55555555459c <dlopen@plt+28>         add    byte ptr [rax], al
0x55555555459e <dlopen@plt+30>         add    byte ptr [rax], al
   ### Next PLT entry...
0x5555555545a0 <__cxa_finalize@plt>    jmp    qword ptr [rip + 0x200a52] <0x7ffff7823520>
 |
 v
0x7ffff7823520 <__cxa_finalize>        push   r15
0x7ffff7823522 <__cxa_finalize+2>      push   r14

问题
  1. 所以，首先...为什么会发生这种情况？
  2. 我以为这应该可行，不是吗？如果没有，为什么？为什么只在两台机器之一上？
  3. 但最重要的是：我该如何解决
    4. ？

    关于问题3，我想强调的全部要点是，我想自己加载该库而不链接它，所以请不要仅评论这是不好的做法，或者其他任何方式。

我一直在与这个问题作斗争很长时间了，但是我一直无法找到解决方案甚至是解释。非常抱歉，如果问题很长，请忍受，因为我只想...

c gcc ld dynamic-linking dynamic-loading
1个回答
0
投票

上面的“应该工作正常™”，的确确实确实如此...

最新问题
© www.soinside.com 2019 - 2025. All rights reserved.