📚 课程目录第2章堆栈原理深度解析

堆栈原理深度解析：Cortex-M内核的“内存舞台”

大家好，我是你们的老朋友。今天咱们来聊聊嵌入式调试里最核心、也最“底层”的东西——堆栈。说实话，我做了十几年嵌入式，见过太多同事在堆栈问题上栽跟头。有的程序跑着跑着就飞了，有的莫名其妙进HardFault，查半天发现是栈溢出了。你想想看，如果连堆栈怎么工作的都不清楚，那调试起来就像蒙着眼睛找路。

这一章，我会把Cortex-M内核的堆栈机制掰开揉碎了讲。从MSP和PSP这两个指针，到函数调用时寄存器怎么入栈，再到栈溢出检测的“金钟罩”——Stack Canary。嗯，内容有点干，但都是硬通货。

2.1 两个堆栈指针：MSP与PSP

Cortex-M内核有两个堆栈指针，这跟很多其他架构不一样。一个是主堆栈指针（MSP），另一个是进程堆栈指针（PSP）。说白了，就是两个不同的栈，用于不同的场景。

特性	MSP（主堆栈指针）	PSP（进程堆栈指针）
默认使用	复位后默认使用，处理异常/中断时自动切换	线程模式下可选使用（通过CONTROL寄存器设置）
典型场景	中断服务函数、内核代码、RTOS调度器	用户任务（线程）的栈空间
栈空间	通常较小，由启动文件分配	每个任务独立分配，大小可配置
访问权限	特权级访问	用户级或特权级（取决于配置）

我记得有一次，一个同事在RTOS里调试任务栈溢出，死活找不到原因。后来发现他一直在看MSP的剩余空间，但任务跑的是PSP。两个栈搞混了，数据当然对不上。所以，调试前先搞清楚当前用的是哪个指针，这是基本功。

调试小技巧： 在调试器里查看当前堆栈指针，可以直接读SP寄存器。但要注意，在异常处理函数里，SP指向的是MSP；在普通任务代码里，SP指向的是PSP（如果启用了进程栈）。可以用 __get_MSP() 和 __get_PSP() 这两个CMSIS函数分别读取。

2.2 函数调用与栈帧结构

每次调用一个函数，CPU都会在栈上压入一组数据，这组数据就叫栈帧。栈帧里存了什么？主要是函数的返回地址、调用者的上下文，还有局部变量。

咱们先看一个典型的C函数调用，编译器会生成什么样的汇编代码：

// C代码
int func(int a, int b) {
    int c = a + b;
    return c;
}

void caller(void) {
    int result = func(1, 2);
}

对应的汇编（简化版，ARM Cortex-M3/M4）：

caller:
    PUSH    {LR}          ; 保存返回地址
    MOV     R0, #1        ; 第一个参数
    MOV     R1, #2        ; 第二个参数
    BL      func          ; 调用func，自动保存PC到LR
    POP     {PC}          ; 恢复返回地址

func:
    PUSH    {R7, LR}      ; 保存R7（帧指针）和LR
    ADD     R7, SP, #0    ; 设置帧指针
    ADD     R3, R0, R1    ; a + b
    STR     R3, [R7, #-4] ; 存到局部变量c
    LDR     R0, [R7, #-4] ; 加载返回值到R0
    MOV     SP, R7        ; 恢复SP
    POP     {R7, PC}      ; 恢复R7，返回地址给PC

这里有个关键点：入栈顺序。在Cortex-M的异常处理中，硬件会自动压栈，顺序是固定的：R0, R1, R2, R3, R12, LR, PC, xPSR。这8个寄存器，一共32字节。为什么是这些？因为它们是函数调用时最可能被破坏的寄存器（Caller-saved registers）。

    核心记忆点： 异常入栈顺序 = R0 → R1 → R2 → R3 → R12 → LR → PC → xPSR。栈是向下生长的，所以PC在栈顶（最低地址），xPSR在栈底（最高地址）。这个顺序在堆栈回溯时至关重要。

我刚开始做堆栈回溯时，总是搞不清哪个地址对应哪个寄存器。后来我画了一张图，贴在工位上，看了半年才彻底记住。来，我直接画给你们看：

为什么硬件要自动压栈？说白了，就是为了保证中断服务函数能安全地使用寄存器，而不破坏被中断任务的上下文。中断返回时，硬件再自动出栈，恢复现场。整个过程对程序员几乎是透明的——但调试时，你必须懂。

2.3 栈溢出检测机制：Stack Canary

栈溢出是嵌入式系统最常见的“隐形杀手”。局部数组越界、递归调用太深、中断嵌套太多……都可能导致栈溢出。溢出的后果很严重：轻则数据被篡改，重则PC指针被改写，程序直接飞掉。

怎么检测？Stack Canary（栈金丝雀） 是一种经典的防护手段。名字来源于矿工用金丝雀检测瓦斯——金丝雀死了，说明有毒气。同理，Canary值被破坏了，说明栈溢出了。

原理很简单：在栈帧的底部（靠近栈顶方向）放一个已知的“哨兵值”。函数返回前，检查这个值有没有被改写过。如果变了，说明发生了栈溢出，立即触发异常处理。

// 伪代码示例：带Canary保护的函数
void func_with_canary(void) {
    // 1. 在栈上放置Canary值
    uint32_t canary = 0xDEADBEEF;  // 已知的哨兵值
    uint32_t __attribute__((aligned(8))) buffer[64];
    
    // ... 业务逻辑 ...
    
    // 2. 返回前检查Canary
    if (canary != 0xDEADBEEF) {
        // 栈溢出了！触发异常
        __asm("BKPT #0");  // 或者调用错误处理函数
    }
}

实际工程中，编译器会帮我们自动插入Canary检查。以GCC为例，开启 -fstack-protector 或 -fstack-protector-strong 选项即可。但要注意，这需要额外的栈空间和运行时开销。

GCC选项	保护范围	性能影响	推荐场景
`-fstack-protector`	仅保护包含局部数组（大小≥8字节）的函数	较小	通用嵌入式项目
`-fstack-protector-strong`	保护所有包含局部数组或局部变量取地址的函数	中等	安全关键系统
`-fstack-protector-all`	保护所有函数	较大	调试阶段或高安全要求

注意： Stack Canary不是万能的。它只能检测到从栈顶方向向下溢出的情况（即覆盖了Canary值）。如果溢出发生在栈帧内部（比如局部数组越界写到了相邻的局部变量），Canary可能检测不到。另外，Canary值本身如果被攻击者猜到，也可以绕过。所以，它只是一个检测手段，不能替代良好的编程习惯。

我曾经在一个工业控制项目里，遇到一个极其隐蔽的栈溢出bug。程序运行几小时后，偶尔会死机。开了 -fstack-protector-strong 后，终于捕获到了异常——一个中断服务函数里，局部缓冲区定义小了，在特定数据长度下会越界。Canary被破坏后，系统直接进入了HardFault。嗯，从那以后，我所有项目都会默认开启栈保护。

2.4 实战：如何手动解析栈帧

假设你遇到了一个HardFault，调试器停在异常处理函数里。你手里只有一堆寄存器和栈内存数据。怎么找到出问题的地方？

步骤很简单：

读取当前SP：如果是MSP，直接读 __get_MSP()；如果是PSP，读 __get_PSP()。
定位栈帧：SP指向的就是异常入栈的栈顶（R0的位置）。
提取PC：从SP+0x1C处读取4字节，这就是发生异常时CPU正在执行的指令地址。
提取LR：从SP+0x14处读取4字节，这是返回地址（调用者的下一条指令）。
反汇编：在PC地址附近看反汇编，找到出错的指令。

// 示例：从栈帧中提取PC和LR
uint32_t *stack_ptr = (uint32_t *)__get_MSP();
uint32_t fault_pc = stack_ptr[7];  // SP + 0x1C
uint32_t fault_lr = stack_ptr[5];  // SP + 0x14

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

我的习惯： 在HardFault_Handler里，我会把MSP和PSP都保存下来，然后打印整个栈帧的内容。这样即使系统复位了，也能从串口日志里看到现场数据。你想想看，如果连现场都丢了，那调试就真成“盲人摸象”了。