elf - 使用 binutils/readelf 确定符号地址

Question

我正在开发一个项目，我们的验证测试脚本需要在正在测试的软件版本中定位符号地址。这可用于设置断点或从内存中读取静态数据。我想要创建一个包含符号名称、内存中基地址和大小的映射文件。我们的构建输出一个 ELF 文件，其中包含我想要的信息。我一直在尝试使用 readelf、nm 和 objdump 工具来尝试获取我需要的符号地址。

我最初尝试了readelf -s file.elf，它似乎访问了一些符号，特别是那些用汇编程序编写的符号。然而，我想要的许多符号并不在那里——特别是那些源 self 们的 Ada 代码的符号。

我使用readelf --debug-dump file.elf转储所有调试信息。从那里我确实看到了所有符号，包括 Ada 代码中的符号。不过格式好像是DWARF格式。有谁知道为什么当我要求 readelf 列出符号信息时这些符号不会被 readelf 输出？也许我只是缺少一个选项。

现在我可以不厌其烦地编写一个自定义的 DWARF 解析器来获取信息，但如果我可以使用 Binutils(nm、readelf、objdump)之一来获取它，那么我真的更喜欢标准解决方案。

Answer 1

DWARF是调试信息，试图反射(reflect)原始源代码的关系。以下面代码为例

static int one() {
  // something
  return 1;
}
int main(int ac, char **av) {
  return one();
}

使用gcc -O3 -g编译后，静态函数one将内联到main中。因此，当您使用readelf -s时，您将永远不会看到符号one。但是，当您使用 readelf --debug-dump 时，您可以看到 one 是一个内联函数。

因此，在这个示例中，编译器不会禁止您使用 -g 进行优化，因此您仍然可以调试可执行文件。在该示例中，即使函数被优化和内联，gdb 仍然可以使用 DWARF 信息从内联函数内的当前代码块中了解函数和源代码/行。

以上只是编译器优化的一个案例。可能有很多原因可能导致 readelf -s 和 DWARF 之间的符号地址不匹配。