为什么编译后符号表仍然存在

Question

我了解符号表是由编译器创建以帮助其处理的。 当它们被链接在一起时，它们存在于每个目标文件中。

假设：

void test(void){
 //
}
void main(){
  return 0;
}

用 gcc 编译上面并运行nm a.out 显示：

0000000100000fa0 T _main
0000000100000f90 T _test

为什么仍然需要这些符号？为什么链接器在完成后不删除它们？对黑客阅读源代码而言，它们不是潜在的安全风险吗？

编辑

这就是你调试发布二进制文件的意思吗（编译时没有-g）？

假设：

int test2(){
 int *p = (int*) 0x123;
 return *p;
}

int test1(){
 return test2();  
}

int main(){
 return test1();
}

test2 上的哪些段错误。正在做gdb ./a.out > where 显示：

(gdb) where
#0  0x000055555555460a in test2 ()
#1  0x000055555555461c in test1 ()
#2  0x000055555555462c in main ()

但是剥离a.out 并做同样的事情：

(gdb) where
#0  0x000055555555460a in ?? ()
#1  0x000055555555461c in ?? ()
#2  0x000055555555462c in ?? ()

这就是keeping symbol tables for debugging release builds 的意思吗？这是正常的做法吗？是否使用了其他工具？

Answer 1

为什么仍然需要这些符号？

它们不是正确执行所必需的，但它们有助于调试。

一些程序可以记录自己的堆栈跟踪（例如TCMalloc 执行分配采样），并在崩溃（或其他类型的错误）时报告它。

虽然所有此类堆栈跟踪都可以离线符号化（给定一个确实包含符号的二进制文件），但程序生成符号化堆栈跟踪通常更方便，所以你不要' t 需要找到匹配的二进制文件。

假设您在云中运行了 1000 多个不同版本的不同应用程序，并且收到了 100 份崩溃报告。它们是同一个崩溃，还是有不同的原因？

如果你只有一堆十六进制数字，那就很难分辨了。您必须为每个实例找到一个匹配的二进制文件，对其进行符号化，并与所有其他实例进行比较（自动化在这里可以提供帮助）。

但如果你有符号化形式的堆栈跟踪，一目了然就很容易分辨。

这确实会带来一些成本：您的二进制文件可能比它们必须的大 1%。

为什么链接器在完成后不删除它们？

您必须记住传统的 UNIX 根源。在开发 UNIX 的环境中，每个人都可以访问所有 UNIX 实用程序的源代码（包括ld），可调试性比保密更重要。所以我对选择这个默认值（保留符号）一点也不感到惊讶。

比较微软做出的选择——将所有内容保存到.DBG（后来的.PDB文件）。

它们不会对黑客阅读源代码构成潜在的安全风险吗？

它们对逆向工程很有帮助，是的。它们不包含源，因此除非源已经打开，否则它们不会添加太多。

不过，如果您的程序包含 CheckLicense() 之类的内容，这有助于黑客集中精力绕过您的许可证检查。

这就是为什么商业二进制文件通常是完全剥离的原因。

更新：

这就是你为调试发布版本保留符号表的意思吗？

是的。

这是正常的做法吗？

这是一种方法。

是否使用了其他工具？

是的：请参阅下面的最佳做法。

附：最佳做法是使用 full 调试信息构建您的二进制文件：

gcc -c -g -O2 foo.c bar.c
gcc -g -o app.dbg foo.o bar.o ...

然后保留完整的调试二进制文件 app.dbg 以供您在需要调试崩溃时使用，但将完全剥离的版本 app 发送给您的客户：

strip app.dbg -o app

附言

gcc -g 用于 gdb。没有 -g 的 gcc 仍然有符号表。

迟早你会发现你必须对一个没有-g构建的二进制文件执行调试（例如当二进制文件没有-g构建时）崩溃，但使用-g 构建的不会崩溃）。

当那个时刻到来时，如果二进制文件仍然有符号表，你的工作会轻松很多。