用g++ -v和nm命令拆解C++编译链接全过程：从符号表到可执行文件

当你第一次在C++项目中看到 .h 和 .cpp 文件分开存放时，可能会疑惑：为什么要把代码拆成两部分？编译器如何知道 main.cpp 调用的函数实现在哪个 .cpp 文件里？为什么有时候会出现"undefined reference"错误？本文将带你用 g++ -v 和 nm 命令，像侦探一样追踪编译链接的每个步骤，亲眼看到符号如何从声明变成可执行文件中的实际调用。

1. 搭建实验环境：最小化多文件项目

我们先创建一个最简单的多文件项目作为实验对象：

mkdir cpp-build-demo && cd cpp-build-demo

创建三个文件：

math_utils.h （头文件）：

#ifndef MATH_UTILS_H
#define MATH_UTILS_H

int square(int x);  // 函数声明

#endif

math_utils.cpp （源文件）：

#include "math_utils.h"

int square(int x) {  // 函数定义
    return x * x;
}

main.cpp （主程序）：

#include <iostream>
#include "math_utils.h"

int main() {
    std::cout << "5的平方是: " << square(5) << std::endl;
    return 0;
}

这个结构展示了典型的C++项目组织方式：

• 头文件（ .h ）包含 声明 （declaration），告诉编译器"有什么"
• 源文件（ .cpp ）包含 定义 （definition），提供具体实现
• 主文件通过 #include 获取声明信息

2. 分步编译：用g++ -v观察详细过程

2.1 预处理阶段：展开所有#include

首先用 -E 选项只执行预处理：

g++ -E main.cpp -o main.ii

查看生成的 main.ii 文件，你会发现：

• #include "math_utils.h" 被替换为 square 函数的声明
• 所有注释都被删除
• 头文件保护宏（ #ifndef MATH_UTILS_H ）被处理

关键观察：

预处理后的文件已经是一个独立的、不依赖其他文件的完整C++源文件

2.2 编译阶段：生成汇编代码

使用 -S 选项生成汇编代码：

g++ -S main.ii -o main.s

查看 main.s ，你会看到类似这样的汇编代码：

call    _Z6squarei  # 调用square函数

这里 _Z6squarei 是编译器生成的 修饰名 （mangled name），包含函数名和参数类型信息。

2.3 汇编阶段：生成目标文件

使用 -c 选项生成目标文件（ .o ）：

g++ -c main.s -o main.o

此时用 nm 命令查看符号表：

nm main.o | grep square

输出可能是：

U _Z6squarei

U 表示这个符号是 未定义 的（Undefined），需要在链接时由其他目标文件提供。

2.4 完整编译过程可视化

使用 -v 选项查看详细编译流程：

g++ -v main.cpp math_utils.cpp -o program

输出会显示：

1. 调用的具体工具链（cc1plus, as, collect2等）
2. 每个阶段使用的命令行参数
3. 搜索的头文件路径
4. 链接的库文件

3. 符号解析：nm命令实战分析

3.1 对比两个目标文件的符号表

编译 math_utils.cpp ：

g++ -c math_utils.cpp -o math_utils.o

查看它的符号表：

nm math_utils.o | grep square

输出可能是：

T _Z6squarei

T 表示这个符号定义在 代码段 （Text section），是可执行的机器指令。

3.2 符号表关键标记解析

常见符号类型：

标记	含义	示例
T	代码段定义的符号	函数实现
U	未定义的符号	需要外部提供的函数
D	已初始化的全局变量	int global = 42;
B	未初始化的全局变量	int global;
C	公共符号	可能被多次定义的全局变量

3.3 链接时的符号匹配过程

当运行链接器时：

1. 收集所有目标文件的符号表
2. 为每个 U 标记的符号寻找对应的 T/D 标记定义
3. 如果找不到匹配的定义，报"undefined reference"错误
4. 如果找到多个定义，报"multiple definition"错误

实验：故意制造链接错误

修改 math_utils.h ，删除 square 的声明，编译时会看到：

main.cpp: 在函数‘main’中:
main.cpp:5:28: 错误：‘square’在此作用域中尚未声明

这展示了声明的重要性——编译器需要在编译阶段知道符号的存在。

4. 高级话题：从目标文件到可执行文件

4.1 重定位（Relocation）实战

使用 objdump 查看重定位信息：

objdump -r main.o

输出会显示哪些地址需要在链接时修正，例如：

RELOCATION RECORDS FOR [.text]:
OFFSET   TYPE              VALUE 
0000001c R_X86_64_PC32     _Z6squarei-0x0000000000000004

这表示在偏移量0x1c处有一个对 square 函数的调用，其地址需要在链接时填充。

4.2 查看最终的可执行文件

链接后查看可执行文件的符号表：

nm program | grep square

输出可能是：

0000000000001159 T _Z6squarei

现在 square 函数已经有了确定的地址（如0x1159），不再是无定义的符号。

4.3 动态链接与静态链接对比

默认情况下，g++使用动态链接：

ldd program

会显示依赖的动态库（如 libstdc++.so ）。

要静态链接标准库，可以：

g++ -static main.cpp math_utils.cpp -o program_static

比较两个可执行文件的大小，静态链接的会大很多。

5. 常见问题与调试技巧

5.1 解决"undefined reference"错误

当遇到链接错误时：

1. 用 nm 检查是否所有需要的符号都有定义
2. 确认所有必要的源文件都参与了编译
3. 检查库文件路径是否正确

5.2 处理"multiple definition"错误

常见原因：

• 头文件中包含了函数定义（非内联）
• 在不同源文件中定义了同名全局变量

解决方案：

• 对函数使用 inline 关键字
• 对变量使用 static 或匿名命名空间
• 遵循"声明在头文件，定义在源文件"原则

5.3 使用c++filt解析修饰名

C++的修饰名难以阅读：

nm math_utils.o | c++filt

输出会将 _Z6squarei 转换为可读的 square(int) 。

5.4 查看段信息

objdump -h program

显示可执行文件中的各个段（section）信息，如：

• .text：代码段
• .data：已初始化数据
• .bss：未初始化数据
• .rodata：只读数据

理解这些底层细节后，下次当你的C++项目出现链接错误时，你就能像侦探一样，用这些工具追踪问题的根源。记住，编译器的详细输出和符号表分析工具是你的最佳助手——它们能让你看到代码背后的真实故事。