2

在分析编译为 ARM 平台的 ELF 文件的 C++ 程序的 .bss 部分时，我遇到了几种确定大小的方法。问题Tool to analyze size of ELF section and symbol中也提到了我测试的四种方法。

然而，结果却大不相同：

bss size according to nm:       35380
bss size according to readelf:  37632
bss size according to size:     37888
bss size according to objdump:  37594

这可能是什么原因？

用于生成输出的 Python 脚本

#!/usr/bin/env python
import re
import subprocess
import sys

fname = sys.argv[1]

# nm
output = subprocess.check_output(['arm-none-eabi-nm','-l','-S','-C',fname])
size = 0
for line in output.splitlines():
    m = re.search('[0-9a-f]* ([0-9a-f]*) ([a-zA-Z]) ([^/]*)\s*([^\s]*)',line)
    if m:
        stype = m.group(2).strip()
        if stype in ['B','b']:
            size += int(m.group(1),16)

print "bss size according to nm: \t%i" % size

# readelf
output = subprocess.check_output(['arm-none-eabi-readelf','-S',fname])
for line in output.splitlines():
    m = re.search('bss\s+[A-Z]+\s+[0-9a-f]+ [0-9a-f]+ ([0-9a-f]+)',line)
    if m:
        print "bss size according to readelf: \t%i" % int(m.group(1),16)
        break

# size
output = subprocess.check_output(['arm-none-eabi-size',fname])
for line in output.splitlines():
    m = re.search('[0-9]+\s+[0-9]+\s+([0-9]+)',line)
    if m:
        print "bss size according to size: \t%i" % int(m.group(1))
        break

# objdump
output = subprocess.check_output(['arm-none-eabi-objdump','-C','-t','-j','.bss',fname])
size = 0
for line in output.splitlines():
    m = re.search('bss\s+([0-9a-f]*)\s+',line)
    if m:
        size += int(m.group(1),16)

print "bss size according to objdump: \t%i" % size

编辑：我发现的一件事是 nm 将函数内部的静态变量（正确地）分类为弱（V），尽管它们可能是 .bss 的一部分。但是，并非所有归类为 V 的部分都是 .bss 的一部分，因此我不能只将所有 V 部分添加到大小中。那么这个任务用 nm 是不可能的吗？

4

1 回答 1

1

这是一个示例汇编文件，它生成一个可执行文件，显示了可能发生的一些事情：

    .section .bss
    .globl var1
    .size var1, 1
var1:
    .skip 1

    .align 16777216
    .globl var2
    .size var2, 1048576
    .globl var3
    .size var3, 1048576
    .globl var4
    .size var4, 1048576
var2:
var3:
var4:
    .skip 1048576

    .text

    .globl main
main:
    xor %eax, %eax
    ret

size -x给出这个输出：

   text    data     bss     dec     hex filename
  0x5c9   0x220 0x2100000   34605033    21007e9 a.out

eu-readelf -S显示基本相同的信息：

[25] .bss                 NOBITS       0000000001000000 01000000 02100000  0 WA     0   0 16777216

但是，符号大小，如 所示eu-readelf -s，完全不同：

   32: 0000000001000001       1 OBJECT  LOCAL  DEFAULT       25 completed.6963
   48: 0000000003000000 1048576 NOTYPE  GLOBAL DEFAULT       25 var2
   49: 0000000003000000 1048576 NOTYPE  GLOBAL DEFAULT       25 var4
   59: 0000000002000000       1 NOTYPE  GLOBAL DEFAULT       25 var1
   61: 0000000003000000 1048576 NOTYPE  GLOBAL DEFAULT       25 var3

它们大小的总和是 0x300002，而不是 0x2100000。有两个因素促成了这一点：

  • 有大约 16 MiB 的间隙，之后var1未使用。var2由于定义变量的顺序，需要实现 的对齐。部分空间被completed.6963.
  • var2, var3,var4是别名：符号值相同，因此只有一个对象支持变量。

此外，由于对齐要求，该部分的末端与该.data部分之间存在相当大的间隙。使用典型的动态加载器，这只会导致未映射的内存区域：.bss.bss

  LOAD           0x000e08 0x0000000000200e08 0x0000000000200e08 0x000220 0x000220 RW  0x200000
  LOAD           0x1000000 0x0000000001000000 0x0000000001000000 0x000000 0x2100000 RW  0x200000

所以size当它不计算这个差距时，它可能是正确的。

此示例中的数字肯定过多，但即使使用常规二进制文件，这些影响也是可见的，只是程度较轻。

readelf/size和objdump/nm差异可能是 ARM 的特性；这些可能是由我的示例中不存在的某些符号类型触发的。

于 2017-10-05T20:06:01.733 回答