C++ ELF对象文件符号表有两次列出的函数
我有一个源文件，它为一个非常大的类定义了一个移动构造函数。我在一个linux系统上用g++ 4.9.2编译它。当我转储结果ELF对象文件的符号表时，我会看到移动构造函数的两个列表。这两个清单都有相同的地址、相同的大小、相同的类型，并且链接器可以很好地链接它，没有发生ODR冲突。当我拆解对象文件时，我只看到一个move构造函数。我的结论是符号表有两个指向相同位置的条目。
同样的行为也发生在这个特定类的构造函数上，这个类是在同一个源文件中定义的。
我看到的唯一不完全理解的编译标志是'-m64'，但我不知道这将如何影响符号表。
我也在g++ 9.2.0中尝试过这一点，现在符号表中有3个条目！其中两个指向相同的地址，第三个点指向地址0x0，位于.text.unlikely部分，并被标记为克隆.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完成的。
回答 1
Stack Overflow用户
发布于 2020-10-24 17:01:19
TL博士:如果你想了解发生了什么
- 不要使用
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构造函数这里的内容。
为什么不使用objdump来查看ELF文件？
objdump是binutils的一部分。虽然binutils仍在积极维护，但它们早在ELF存在之前就已经编写，并且使用libbfd。后者有一个内部数据模型，无法充分描述ELF文件格式。
因此，当您对一个objdump文件使用ELF时，libbfd首先将该文件解析为这个内部/不足的数据模型，然后objdump以人类可读的形式显示该模型。在翻译中有很多东西会丢失。
https://stackoverflow.com/questions/64505490
复制相似问题
腾讯云开发者
