Android共享库的节大小总和大于共享的lib大小

Question

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

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

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

使用的命令： 要捕获截面尺寸： prebuilts / gcc / linux-x86 / arm / arm-eabi-4.6 / arm-eabi / bin / objdump -x

要计算共享库的文件大小： ls -l <​​/ p>

Answer 1

你还没有发布实际的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

这里有三种不同的部分：

• .data是一个“普通”部分，设置了CONTENTS，ALLOC和LOAD个标记。
• .bss没有要存储或加载的实际数据，因此它只有ALLOC。
• .gnu_debuglink根本不适用于正在运行的程序;它没有VMA或LMA设置，并且没有设置ALLOC或LOAD标志，尽管它确实有CONTENTS（用于链接/调试目的）