GCC的nm列出了方法的多个条目

时间:2015-06-29 02:34:26

标签: c++ gcc virtual nm

对于nm列出的单个方法,有多个条目是正常的吗?我运行了以下内容:

nm -C myObjectFile.o | grep MyObject::

并收到以下内容:

... stuff...
... stuff...
0000027e0 T MyObject::MyObject(MyDepend*)
0000027e0 T MyObject::MyObject(MyDepend*)
000000030 T MyObject::~MyObject()
000000000 T MyObject::~MyObject()
000000000 T MyObject::~MyObject()
000000060 T non-virtual thunk to MyObject::~MyObject()
000000020 T non-virtual thunk to MyObject::~MyObject()

这对我来说似乎不对。你觉得不对吗?如果是这样,你能详细说明它为什么是错误的,是什么原因造成的?如果只在某些情况下它是正确的,那么我将解释更多关于我看到nm输出的问题,我们可以从那里开始。

1 个答案:

答案 0 :(得分:1)

在某些情况下,demangler会将不同的输入解码为同一输出。我认为这有点令人困惑,但我认为这样做是因为在其他情况下它不那么令人困惑;例如,dedbngler由gdb使用,这种方法允许构造函数上的断点做正确的事情而无需用户的额外努力。也许通过一些思考和工作可以实现一些改进。

无论如何,这是一个简单的例子:

class K
{
  K ();
  virtual ~K();
};

K::K() { }
K::~K() { }

使用-g进行编译,然后运行nm -C会显示与您类似的结果:

$ nm -C q.o
         U operator delete(void*)
0000000000000000 T K::K()
0000000000000000 T K::K()
0000000000000048 T K::~K()
0000000000000018 T K::~K()
0000000000000018 T K::~K()
0000000000000000 V typeinfo for K
0000000000000000 V typeinfo name for K
0000000000000000 V vtable for K
         U vtable for __cxxabiv1::__class_type_info

但是让我们看看如果我们运行普通nm会发生什么:

$ nm q.o
         U _ZdlPv
0000000000000000 T _ZN1KC1Ev
0000000000000000 T _ZN1KC2Ev
0000000000000048 T _ZN1KD0Ev
0000000000000018 T _ZN1KD1Ev
0000000000000018 T _ZN1KD2Ev
0000000000000000 V _ZTI1K
0000000000000000 V _ZTS1K
0000000000000000 V _ZTV1K
         U _ZTVN10__cxxabiv117__class_type_infoE

在这里,我们可以更清楚地看到底层符号是不同的。

从这里我们可以去C++ ABI that GCC follows;特别是有关修复构造函数和析构函数的部分。由于历史原因,这称为“Itanium”ABI,但实际上它在所有平台上都使用(可能有少量变体)。

本节解释了名称的含义,但您必须深入了解文档才能完全理解。基本思想是,在C ++的实现中,需要构造函数和析构函数的不同入口点;这是通过为不同的入口点提供不同的符号来完成的。