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

Question

我有一个源文件，它为一个非常大的类定义了一个移动构造函数。我在 Linux 系统上用 g++ 4.9.2 编译它。当我转储生成的 ELF 对象文件的符号表时，我看到 2 个移动构造函数列表。两个列表具有相同的地址、相同的大小、相同的类型，并且链接器将其链接得很好，没有违反 ODR。当我反汇编目标文件时，我只看到一个移动构造函数。我的结论是符号表有两个指向同一位置的条目。
同样的行为也会发生在这个特定类的构造函数中，它在同一个源文件中定义。
我看到的唯一一个我不完全理解的编译标志是“-m64”，但我不知道这将如何影响符号表。
我也用 g++ 9.2.0 尝试过这个，现在我在符号表中有 3 个条目!其中两个指向同一个地址，第三个指向地址 0x0，位于 .text.unlikely 部分，并标记为 [clone .cold]。
为什么是这样？

编辑:实际上，我可以在家里用很小的类(class)来重现这一点。

// 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:文件格式 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:如果你想了解发生了什么

不要使用 objdump要检查 ELF 文件，请使用 readelf相反(见下文)

不要用 c++filt 来破坏名称-- 不同的符号可以产生相同的解构名称(即它不是一对一的转换)。

细节:

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构造函数 here .
附言为什么你永远不应该使用 objdump看 ELF文件？ objdump是 binutils 的一部分.虽然 binutils仍在积极维护中，它们早在 ELF 之前就已写好存在，并使用 libbfd .后者具有无法充分描述的内部数据模型 ELF文件格式。
所以当你使用 objdump在 ELF 上文件，第一个 libbfd将文件解析为这个内部/不适当的数据模型，然后 objdump以人类可读的形式呈现这个模型。在翻译中丢失了很多东西。