C++雾中风景15:聊聊让人抓狂的Name Mangling
Name Mangling,直接翻译过来为名字改写 。它是深入理解 C++ 编译链接模型的必由之路。
笔者近期进行数据库开发工作时,涉及到MySQL客户端的编译链接的问题,通过重新厘清了之前理解一知半解的Name Manging,解决了让人抓狂的编译链接问题。
接下来,和大家聊聊C++的Name Mangling。
1.什么是Name Mangling
1.1 Name Mangling的作用
在进行编程的过程之中,我们常常遇见变量或函数重名的情况。比如:函数的重载,或通过不同程序块与命名空间变量与函数的重名。
而在出现变量或函数名相同的情况下,编译器进行代码编译时需要保证变量与函数的签名的全局唯一性。如果无法进行上述保证,在链接阶段就会产生链接的二义性,会导致编译器不知道应该如何取用正确的变量与函数符号的内存地址。
为了解决上述问题,编译器实现了一种叫做Name Mangling的方式:它通过一个固定的命名规则来重新组织源代码之中我们定义的变量名和函数名,来确保了能够将被链接的目标文件中的符号签名的唯一性。(由于在C++的标准之中,并未强制规定Name Mangling的实现机制,所以不同的编译器在不同的平台上实现是完全不同的。笔者的后续关于Name Mangling的讲解将基于Linux上的GCC展开。)
1.2 举个栗子
上述内容讲明白了Name Mangling的意义,我们来通过实际的代码来瞅瞅它是如何生效的。
首先看看如下代码:
#include <iostream>
#include <string>
#include <vector>
namespace Happen {
struct MyClass {
std::vector<std::string> _str_vec;
};
}
int main() {
Happen::MyClass myClass;
return 0;
}
接下来,我们使用g++获取它的汇编代码
g++ -S main.cpp
使用编辑器打开生成的main.s
文件,我们就可以看到下面这些被Name Mangling之后的命名了。
call _ZN6Happen7MyClassC1Ev
movl $0, %ebx
leaq -48(%rbp), %rax
movq %rax, %rdi
call _ZN6Happen7MyClassD1Ev
这里可以看到,代码调用了_ZN6Happen7MyClassC1Ev
与_ZN6Happen7MyClassD1Ev
这两个函数。这其实就是代码之中调用了我们定义的MyClass的构造函数与析构函数。而这里令人望而生畏的命名就是Name Mangling的功劳啦~~
2. Name DeMangling
既然有了Name Mangling了,自然就要有Name DeMangling。上面的_ZN6Happen7MyClassC1Ev还能大概齐猜测出意思,但是你确定你能看懂下面的这一长串Name Mangling之后的结果:
MN6Happen7MyClassESt6vectorINSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEESaIS7_EE
2.1 通过API进行Name DeMangling
在C++之中,我们常常使用typeid
,来获取类型的type_info
信息,而Name Mangling就包含在type_info
之中,我们来看如下代码:
#include <iostream>
#include <string>
#include <vector>
namespace Happen {
struct MyClass {
std::vector<std::string> _str_vec;
};
}
int main() {
std::cout << typeid(&Happen::MyClass::_str_vec).name() << "\n";
return 0;
}
它的输出正是上面那串让人「抓狂」的命名,我们现在尝试通过GNU的API来脱掉它的马甲,真正的看看它到底是啥。
这里使用了abi::__cxa_demangle
来获取DeMangling时真正的结果。
#include <iostream>
#include <string>
#include <vector>
#include <cxxabi.h>
namespace Happen {
struct MyClass {
std::vector<std::string> _str_vec;
};
}
int main() {
char* real_name = abi::__cxa_demangle(typeid(&Happen::MyClass::_str_vec).name(), \
nullptr, nullptr, nullptr);
std::cout << real_name << "\n";
return 0;
}
这是通过Name DeMangling实际输出的结果。(囧rz,好像可读性也并没有太好,C++的类型系统实在是太复杂了,不过起码能让我们看清楚真正的名字是啥了。)
std::vector<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >, std::allocator<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > > > Happen::MyClass::*
2.2 使用nm或c++filt进行Name Demangling
通过代码进行名字辨析确实会带来诸多不便,所以Linux提供了两个好用的工具:
nm与c++filt,它们可以作用在二进制文件,函数链接库等之上(nm其实就是name mangling的缩写)
通过nm的-C
参数就可以直接输出name demangling之后的结果了。
nm -C bin/.so/.a
或者也可以通过c++filt
来实现同样的功能
nm bin/.so/.a | c++filt
3.C语言的Name Mangling
C++能够支持调用C语言的函数,同样也支持实现函数库被C语言调用,这个过程之中就涉及到两种语言交互的Name Mangling了。(这个问题会常常导致编译时出现令人抓狂的undefined reference to 『xxx』, 很多时候会让人丈二和尚摸不着头脑)
3.1 两者的区别
由于C语言不支持函数重载,命名空间,类等逻辑,所以C语言的Name Mangling比C++简单很多。我们来看看通过gcc和g++的编译结果有和不同吧,首先我们定义一个简单的函数sum
:
int sum(int a, int b) {
return a + b;
}
- g++的编译结果
_Z3sumii
- gcc的编译结果
sum
这里可以明显看到二者的不同,由于C++支持函数重载。所以需要在Name Mangling时添加参数的信息,也就是后面的两个ii
,指代两个int
类型。
3.2 extern "C"
所以通过C++定义的函数需要被C语言调用时,需要通过keyword:extern C
来显式的让编译器明白需要使用C语言的Name Mangling规则,以便编译器链接时能够正确的识别函数签名来定位到所需的函数。
extern "C" {
int sum(int a, int b) {
return a + b;
}
};
将上述函数改写为上面的方式之后,通过g++编译的结果也变为了我们所期待的sum
了。
4.小结
C++的编译链接问题常常让人抓狂,很多时候如果没有深入了解这个过程之中的逻辑,很容易陷入困境。本篇聊了聊笔者在遇到编译问题时学习Name Mangling来最终解决问题的学习小结。
希望大家能够有所收获,笔者水平有限。成文之处难免有理解谬误之处,欢迎大家多多讨论,指教。