📚 课程目录第4章 Call Stack与函数调用追踪

4. Call Stack 与函数调用追踪：堆栈回溯原理、查看调用链、栈溢出检测

调试嵌入式系统，说白了就是跟函数调用栈打交道。我见过不少工程师，一遇到 HardFault 就慌了神，盯着反汇编代码发呆。其实你只要读懂了 Call Stack，大部分问题都能找到线索。

这一章，我们就来聊聊堆栈回溯的原理、怎么查看调用链，以及如何检测栈溢出。嗯，这些都是我日常排查问题时的基本功。

4.1 堆栈回溯原理：CPU 是怎么记住“我从哪来”的？

先问个问题：CPU 执行完一个函数后，怎么知道该回到哪里？

答案就在栈里。每次调用函数，CPU 都会把返回地址压入栈中。这个返回地址，就是调用者下一条指令的地址。当函数执行完毕，CPU 从栈里弹出这个地址，跳回去继续执行。

堆栈回溯（Stack Unwinding），就是逆向这个过程——从当前栈帧出发，沿着返回地址链，一路追溯到 main 函数。

核心概念：栈帧（Stack Frame）

每个函数调用都会在栈上分配一块区域，用来存放：

返回地址（Return Address）
上一帧的帧指针（FP/LR）
局部变量
保存的寄存器

以 ARM Cortex-M 为例，它的调用约定是这样的：

// 函数 A 调用函数 B
void A(void) {
    B();  // BL B 指令：将返回地址存入 LR，然后跳转到 B
}

void B(void) {
    // 进入 B 时，LR 里存的是 A 中 B() 的下一条指令地址
    // 如果 B 还要调用其他函数，必须先把 LR 压栈
    C();
    // 返回时，从栈中恢复 LR，然后 BX LR
}

我个人习惯在调试时，先看 LR 寄存器的值。如果 LR 的值看起来不像代码区地址（比如 0xDEADBEEF），那基本可以断定栈已经被破坏了。

4.2 查看调用链：从 IDE 到命令行

查看调用链，最直观的方式是用 IDE 的调试器。但有时候你手头只有串口终端，或者芯片已经死机了，这时候就得靠手动解析。

4.2.1 IDE 调试器查看 Call Stack

在 Keil、IAR 或 STM32CubeIDE 里，断点停下后，Call Stack 窗口会列出当前调用链。双击任意一层，编辑器会跳转到对应的源代码行。

但要注意——如果代码被优化过，调试器可能无法正确展开调用链。我遇到过好几次，优化等级开到 -O2 后，Call Stack 窗口里只剩一个函数名，其他全丢了。

我的建议：调试阶段先用 -O0 编译，等功能稳定后再开优化。否则你看到的调用链可能是不完整的，反而浪费时间。

4.2.2 手动解析：从栈内存还原调用链

当芯片死机、调试器连不上时，你只能靠手动解析。步骤如下：

读取当前 SP（栈指针）的值
从 SP 开始，向上遍历栈内存
寻找看起来像返回地址的值（落在代码区范围内）
根据芯片架构，解析每个栈帧的 LR 和 FP

举个例子，Cortex-M 在进入异常时，会自动将 8 个寄存器压栈：R0-R3、R12、LR、PC、xPSR。你只要找到栈顶的 PC 值，就能知道死机时 CPU 正在执行哪条指令。

// 手动解析示例：从栈内存提取 PC
uint32_t *stack = (uint32_t *)__get_MSP();
uint32_t pc_at_fault = stack[6];  // 第 7 个压栈的是 PC
uint32_t lr_at_fault = stack[5];  // 第 6 个压栈的是 LR

printf("Fault PC: 0x%08X\n", pc_at_fault);
printf("Fault LR: 0x%08X\n", lr_at_fault);

注意：手动解析时，一定要确认栈指针的有效性。如果 SP 已经跑飞了，读出来的数据全是垃圾。我曾经在排查一个野指针问题时，SP 指向了 0x20000000 之外的地址，读出来的 PC 值完全不对，后来才发现是栈被踩穿了。

4.3 栈溢出检测：别让 Bug 藏得太深

栈溢出是嵌入式系统里最隐蔽的问题之一。它不会立刻崩溃，而是慢慢侵蚀相邻的内存区域——可能是全局变量，也可能是堆空间。等你发现时，现象已经变得非常诡异了。

4.3.1 栈溢出的典型症状

症状	可能原因	排查方向
函数返回后跑飞	返回地址被覆盖	检查局部数组是否越界
全局变量无故变化	栈向下增长，覆盖了全局区	检查栈顶与全局区是否相邻
递归函数卡死	递归深度过大，耗尽栈空间	限制递归深度，改用迭代
中断嵌套后死机	中断栈与主栈共用，嵌套过深	配置独立的中断栈

4.3.2 栈溢出检测方法

我常用的方法有三种，按可靠性排序：

方法一：栈填充检测（最常用）

在系统初始化时，用固定模式（如 0xDEADBEEF）填充整个栈空间。然后定期检查栈空间末尾的模式是否被破坏。

// 栈填充检测示例
#define STACK_FILL_PATTERN 0xDEADBEEF
#define STACK_WATERMARK_THRESHOLD 64  // 保留 64 字节警戒区

void Stack_Init(void) {
    uint32_t *stack_start = (uint32_t *)STACK_START;
    uint32_t *stack_end   = (uint32_t *)STACK_END;
    
    for (uint32_t *p = stack_start; p < stack_end; p++) {
        *p = STACK_FILL_PATTERN;
    }
}

uint32_t Stack_GetUsage(void) {
    uint32_t *p = (uint32_t *)STACK_START;
    uint32_t count = 0;
    
    while (*p == STACK_FILL_PATTERN) {
        count++;
        p++;
    }
    
    return (STACK_SIZE - count * 4);  // 返回已使用的字节数
}

void Stack_CheckOverflow(void) {
    uint32_t *p = (uint32_t *)(STACK_END - STACK_WATERMARK_THRESHOLD);
    if (*p != STACK_FILL_PATTERN) {
        // 警戒区被破坏，触发告警
        Error_Handler("Stack overflow detected!");
    }
}

方法二：MPU 保护（硬件级）

如果芯片有 MPU（内存保护单元），可以直接在栈底设置一个不可读写的保护区。一旦栈溢出触及这个区域，CPU 会立即触发 MemManage Fault。

我的经验：MPU 保护是最可靠的，但配置起来比较麻烦。我一般在产品开发后期才加上，前期用栈填充法就够了。

方法三：编译器内置检查

GCC 提供了 -fstack-protector 选项，会在栈帧中插入 canary 值。函数返回前检查 canary 是否被修改，如果变了就调用 __stack_chk_fail。

// 编译时加上 -fstack-protector-strong
// 编译器会自动插入 canary 检查

void vulnerable_function(void) {
    char buffer[64];
    // 如果这里越界写，canary 会被破坏
    // 函数返回前会触发 __stack_chk_fail
    gets(buffer);  // 危险！仅作示例
}

4.3.3 避坑指南：我曾经踩过的坑

我曾经在一个 RTOS 项目里，遇到一个间歇性死机的问题。现象是系统运行几小时后，某个任务突然挂掉，但其他任务还能正常工作。

排查了整整两天，最后发现是这个任务的栈空间分配得太小——只有 256 字节。而它调用的一个函数里，声明了一个 128 字节的局部数组，再加上函数嵌套调用，栈空间瞬间爆了。

更坑的是，栈溢出没有立刻触发 HardFault，而是覆盖了相邻任务的 TCB（任务控制块）。那个任务在下次调度时，从 TCB 里读到了一个错误的栈指针，直接跳到了非法地址。

教训：RTOS 下每个任务的栈空间，一定要留足余量。我现在的习惯是：估算最大使用量后，再乘以 1.5 到 2 倍。同时，在任务创建时用栈填充法，定期检查使用峰值。

4.4 知识结构图：Call Stack 与栈溢出检测全景

下面这张图，把本章的核心知识点串了起来。你可以把它当作排查时的路线图。

4.5 小结

这一章我们聊了堆栈回溯的原理、查看调用链的几种方式，以及栈溢出的检测方法。说白了，Call Stack 就是程序的“导航日志”——你只要学会读它，大部分运行时问题都能找到根因。

我个人觉得，栈溢出检测是嵌入式开发里最容易被忽视的环节。很多工程师直到产品量产了，才发现某些设备在特定工况下会死机。嗯，与其事后救火，不如在设计阶段就把检测机制加进去。