1

在 Android 中，如果我使用 objdump 工具分析共享库，我会观察到以下情况：

共享库中部分大小的总和小于二进制文件大小。这是可以理解的，二进制大小 = ELF 头大小 + 程序头大小 + 节大小 + 节头大小。

但是，对于另一个共享库，节大小的总和大于共享库文件本身的大小！这似乎非常令人惊讶。有没有可能发生这种情况？

使用的命令：捕获部分大小：prebuilts/gcc/linux-x86/arm/arm-eabi-4.6/arm-eabi/bin/objdump -x

计算共享库的文件大小：ls -l

4

1 回答 1

0

您还没有发布实际的 objdump 输出（为什么？），所以我只是猜测，但这可能是因为该.bss部分。

.bss包含程序启动时未显式初始化的所有静态或全局变量。因为它们没有初始值，所以二进制文件不需要包含任何实际值。该部分只是作为占位符。它将有元数据（大小、位置、符号偏移），但没有实际数据。

当您将程序加载到内存中以运行它时，实际上不需要从文件中加载任何内容，但是 ELF 加载器会在正确的位置保留适当数量的内存，而程序的工作就是归零-初始化该内存（通常crt1.o代码会这样做）。

这是一个例子：

objdump -x /bin/bash
....
Idx Name          Size      VMA               LMA               File off  Algn
....
 24 .data         00008360  00000000006db620  00000000006db620  000db620  2**5
                  CONTENTS, ALLOC, LOAD, DATA
 25 .bss          00005a48  00000000006e3980  00000000006e3980  000e3980  2**5
                  ALLOC
 26 .gnu_debuglink 0000000c  0000000000000000  0000000000000000  000e3980  2**0
                  CONTENTS, READONLY

这里有三种不同的部分：

  • .dataCONTENTS是设置了,ALLOC和LOAD标志的“正常”部分。
  • .bss没有要存储或加载的真实数据，所以它只有ALLOC.
  • .gnu_debuglink根本不适合正在运行的程序；它没有设置VMA或LMA设置，也没有设置ALLOC或LOAD标志，尽管它确实有真实的CONTENTS（用于链接/调试目的）
于 2013-11-06T13:40:55.670 回答