Android 共享库总和大于共享库大小答案

【问题标题】：Android shared library sum of sections size is greater than shared lib sizeAndroid 共享库总和大于共享库大小
【发布时间】：2013-11-06 06:33:01
【问题描述】：

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

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

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

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

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

【问题讨论】：

标签： android c gcc shared-libraries elf

【解决方案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（用于链接/调试目的）

【讨论】：