elf 文件中析构函数的位置：不应该在哪里？答案

【问题标题】：Location of destructors in elf files: not where it should be?elf 文件中析构函数的位置：不应该在哪里？
【发布时间】：2013-11-15 14:51:38
【问题描述】：

我注册了一个令牌析构函数

static void cleanup __attribute__ ((destructor));

该函数只是打印一条调试消息；令牌程序运行良好（main() 只是打印另一条消息；令牌函数在退出时打印）。

当我查看文件时

nm ./a.out,

我明白了：

08049f10 d __DTOR_END__

08049f0c d __DTOR_LIST__

但是，令牌析构函数的地址应该在0x08049f10 - 一个包含 0 的地址，表示析构函数列表的结尾，我可以使用以下方法进行检查：

objdump -s ./a.out

在0x08049f0c，我看到0xffffffff，正如预期的那样。据我了解，我在 elf 文件中看到的内容意味着没有注册析构函数；但它是用一个执行的。

如果有人能解释一下，我将不胜感激。安全套件的这一部分是为了防止插入恶意析构函数吗？编译器如何跟踪析构函数的地址？

我的系统：

Ubuntu 12.04。
elf32-i386
内核：3.2.0-30-generic-pae
gcc 版本：4.6.3

【问题讨论】：

我不知道如何解决布局问题：粗体属性（在 nm p/o 后面类似）实际上是带有 2 个前导和尾随 _ 的属性。
是的，那里的格式看起来很奇怪；会不会是一些无法打印的字符？（与此同时，我试图修复它；看起来对吗？）
完美！非常感谢。我之前注意到从我的 iPhone 提交 SO 会产生不正确的布局。也许就是这样。
你能在 Meta 上搜索吗？那里可能有一个关于它的问题。
GCC 确实为 C 中的构造函数和析构函数提供了支持 - 请参阅 gcc.gnu.org/onlinedocs/gcc/Function-Attributes.html。

标签： c gcc destructor elf

【解决方案1】：

DTOR_LIST 是析构函数表的开始。看看它在哪个部分（可能是 .dtors）：

~> objdump -t test | grep DTOR_LIST
0000000000600728 l     O .dtors 0000000000000000              __DTOR_LIST__

然后用 readelf（或其他）转储该部分：

~> readelf --hex-dump=.dtors test

Hex dump of section '.dtors':
  0x00600728 ffffffff ffffffff 1c054000 00000000 ..........@.....
  0x00600738 00000000 00000000                   ........

在我的测试用例中，它可能包含几个 -1、一个实指针，然后是零终止。

【讨论】：