C++ ELF 目标文件符号表的函数列出了两次

Question

我有一个源文件，它为一个非常大的类定义了移动构造函数。我在 Linux 系统上用 g++ 4.9.2 编译它。当我转储生成的 ELF 对象文件的符号表时，我看到 2 个移动构造函数的列表。两个列表具有相同的地址、相同的大小、相同的类型，并且链接器链接得很好，没有 ODR 违规。当我反汇编目标文件时，我只看到一个移动构造函数。我的结论是符号表有两个指向同一位置的条目。

同样的行为也会发生在这个特定类的构造函数中，该类是在同一个源文件中定义的。

我看到的唯一一个我不完全理解的编译标志是“-m64”，但我不知道这将如何影响符号表。

我也用 g++ 9.2.0 尝试过，现在符号表中有 3 个条目！其中两个指向同一个地址，第三个指向地址0x0，位于.text.unlikely部分，并被标记为[clone .cold]。

为什么是这样？

---

编辑：实际上，我可以在家里用一个很小的班级重现这个。

// class.h
class VeryLargeClass
{
    int data;

    public:
    VeryLargeClass(VeryLargeClass&&);
};

// class.cpp
#include "class.h"

VeryLargeClass::VeryLargeClass(VeryLargeClass&& other)
{
    data = other.data;
    other.data = 0;
}

如果我用 编译它g++ -c -O3 class.cpp -o class.o，然后用 转储符号表，objdump -t class.o | c++filt我会得到以下内容： class.o: file format elf64-x86-64

SYMBOL TABLE:
0000000000000000 l    df *ABS*  0000000000000000 main.cc
0000000000000000 l    d  .text  0000000000000000 .text
0000000000000000 l    d  .data  0000000000000000 .data
0000000000000000 l    d  .bss   0000000000000000 .bss
0000000000000000 l    d  .note.GNU-stack    0000000000000000 .note.GNU-stack
0000000000000000 l    d  .eh_frame  0000000000000000 .eh_frame
0000000000000000 l    d  .comment   0000000000000000 .comment
0000000000000000 g     F .text  000000000000000b VeryLargeClass::VeryLargeClass(VeryLargeClass&&)
0000000000000000 g     F .text  000000000000000b VeryLargeClass::VeryLargeClass(VeryLargeClass&&)

请注意移动构造函数如何在符号表中出现两次？我猜我只是不了解 ELF 格式。这是使用 g++ 10.2 完成的。

Answer 1

TL;DR：如果你想了解发生了什么

1. 不要用于objdump检查 ELF 文件，readelf而是使用（见下文）
2. don't demangle name with c++filt-- 不同的符号可以产生相同的demangle名称（即它不是一对一的转换）。

细节：

cat foo.cc

struct Foo {
  Foo(Foo&& f);
  void *p;
};

Foo::Foo(Foo &&f) {
  p = f.p;
  f.p = nullptr;
}

g++ -c foo.cc
objdump -t foo.o | grep Foo | c++filt

0000000000000000 g     F .text  0000000000000028 Foo::Foo(Foo&&)
0000000000000000 g     F .text  0000000000000028 Foo::Foo(Foo&&)

objdump -t foo.o | grep Foo 
0000000000000000 g     F .text  0000000000000028 _ZN3FooC2EOS_
0000000000000000 g     F .text  0000000000000028 _ZN3FooC1EOS_

请注意，符号是不同的。您可以在此处阅读有关C1和C2构造函数的信息。

PS 为什么你不应该用它objdump来查看ELF文件？

objdump是其一部分binutils。虽然binutils仍在积极维护，但它们早在ELF存在之前就已编写，并且使用libbfd. 后者具有无法充分描述ELF文件格式的内部数据模型。

因此，当您在文件objdump上使用时ELF，首先libbfd将文件解析为内部/不充分的数据模型，然后以 objdump人类可读的形式呈现该模型。翻译过程中会丢失很多东西。