栈的工作原理与溢出检测：从帧结构到MPU/Canary实战

栈这个东西，说白了就是嵌入式系统的"临时工作台"。每次函数调用，CPU都会在上面铺一块"桌布"——这就是栈帧。我在项目中见过太多因为栈溢出导致的诡异故障：系统跑着跑着就重启，或者某个全局变量莫名其妙被篡改。嗯，今天我们就把它彻底讲透。

栈帧结构：CPU的临时工作台

每次调用函数，编译器都会在栈上分配一块区域，用来存放局部变量、函数参数、返回地址和保存的寄存器。这块区域就是栈帧。ARM Cortex-M的栈帧布局大致如下：

栈地址（高→低）	内容	说明
SP+0x10	局部变量3	函数内定义的第三个局部变量
SP+0x0C	局部变量2	函数内定义的第二个局部变量
SP+0x08	局部变量1	函数内定义的第一个局部变量
SP+0x04	保存的LR	返回地址，函数结束后跳回这里
SP+0x00	保存的R4	被调用者保存的寄存器

注意，栈是向下生长的。SP指针从高地址往低地址移动。每次push操作，SP先减4，再存数据。pop则相反。这个顺序搞反了，数据就全乱了。

SP指针操作：别让指针"越界"

SP指针是栈的灵魂。它指向当前栈顶。在ARM Cortex-M上，SP有主栈指针(MSP)和进程栈指针(PSP)之分。中断处理用MSP，任务用PSP。我个人习惯在启动代码里就把两个栈的边界都设好。

SP指针的典型操作序列：

// 伪代码：函数调用时的栈操作
function func(int a, int b) {
    // 1. 保存返回地址 (LR入栈)
    PUSH {LR}
    
    // 2. 保存被调用者保存的寄存器
    PUSH {R4-R7}
    
    // 3. 为局部变量分配空间
    SUB SP, SP, #16  // 分配16字节
    
    // 4. 函数体...
    
    // 5. 恢复栈指针
    ADD SP, SP, #16
    
    // 6. 恢复寄存器
    POP {R4-R7}
    
    // 7. 返回
    POP {PC}
}

你想想看，如果第3步分配的空间太大，或者递归层数太多，SP就会一路往下冲，直到撞上堆区或者全局变量区。那时候，什么奇怪的问题都可能出现。

递归深度限制：别让函数"套娃"

递归是栈溢出的头号杀手。我曾经接手过一个项目，同事用递归实现了一个树形菜单遍历，菜单深度只有5层时跑得好好的。结果客户数据里有一棵深度20层的树——系统直接死机。

递归深度怎么算？很简单：

// 递归深度 = 可用栈空间 / 单次递归栈帧大小
// 假设可用栈空间 2048 字节，每次递归消耗 64 字节
// 最大递归深度 = 2048 / 64 = 32 层

// 实际代码中建议留 50% 余量
#define MAX_RECURSION_DEPTH 16

static int recursion_count = 0;

void safe_recursive_func(void) {
    if (recursion_count >= MAX_RECURSION_DEPTH) {
        // 触发错误处理
        error_handler("Recursion depth exceeded!");
        return;
    }
    recursion_count++;
    // 实际递归逻辑...
    recursion_count--;
}

栈溢出检测：MPU与Canary技术

栈溢出检测有两种主流方案：硬件方案（MPU/MMU）和软件方案（Canary）。我建议在关键系统中两者都用。

MPU检测：硬件级的"防火墙"

MPU（内存保护单元）可以给栈区域设置访问权限。当SP指针越界访问时，MPU会触发异常。配置方法如下：

// ARM Cortex-M3/M4 MPU配置示例
void MPU_Config_Stack_Guard(void) {
    // 1. 禁用MPU
    MPU->CTRL = 0;
    
    // 2. 配置栈底区域为"不可访问"
    // 假设栈底在 0x20001000，栈大小 1024 字节
    // 在栈底下方设置一个 32 字节的"禁区"
    MPU->RBAR = (0x20000FE0 & 0xFFFFFFE0)  // 对齐到32字节
                | MPU_REGION_NUMBER_0;
    MPU->RASR = (MPU_REGION_SIZE_32B)       // 32字节区域
                | MPU_AP_NONE               // 完全不可访问
                | MPU_REGION_ENABLE;
    
    // 3. 配置栈区域为"可读写"
    MPU->RBAR = (0x20001000 & 0xFFFFFFE0)
                | MPU_REGION_NUMBER_1;
    MPU->RASR = (MPU_REGION_SIZE_1KB)
                | MPU_AP_RW_RW              // 特权+用户可读写
                | MPU_REGION_ENABLE;
    
    // 4. 启用MPU
    MPU->CTRL = MPU_PRIVDEFENA | MPU_ENABLE;
}

当SP指针降到0x20000FE0以下时，MPU立即触发MemManage Fault。这时候你可以在fault handler里记录现场，然后安全重启。我在一个医疗设备项目里用这个方案，成功捕获了3次栈溢出——都是因为某个驱动库的递归调用没控制好。

Canary检测：软件"金丝雀"

Canary技术源自煤矿工人用金丝雀检测毒气的做法。我们在栈的"危险边界"放一个特殊值（Canary），然后定期检查它是否被改写。

// Canary检测实现
#define CANARY_VALUE 0xDEADBEEF
#define STACK_SIZE   1024

static uint32_t stack_pool[STACK_SIZE / 4];
static uint32_t *canary_ptr;

void stack_init(void) {
    // 在栈底放置Canary
    canary_ptr = &stack_pool[0];
    *canary_ptr = CANARY_VALUE;
    
    // 初始化栈指针
    // 注意：栈向下生长，Canary在栈底（低地址）
    uint32_t *sp = &stack_pool[STACK_SIZE / 4 - 1];
    __set_MSP((uint32_t)sp);
}

bool stack_check_canary(void) {
    if (*canary_ptr != CANARY_VALUE) {
        // Canary被破坏，栈溢出！
        return false;
    }
    return true;
}

// 在任务切换或关键操作后调用
void task_switch_hook(void) {
    if (!stack_check_canary()) {
        // 记录错误信息
        error_log("Stack overflow detected in task %d", current_task);
        // 执行安全恢复
        system_safe_recovery();
    }
}

三种检测方案对比

方案	检测时机	硬件开销	软件开销	误报率
MPU硬件保护	实时（访问时触发）	需要MPU硬件	几乎为零	极低
Canary软件检测	定期检查	无	每次检查约5-10μs	低（取决于检查频率）
栈指针边界检查	函数入口/出口	无	每次调用约2-3μs	中等（可能漏检）

我个人推荐的做法是：有MPU的芯片就用MPU做第一道防线，同时用Canary做第二道防线。没有MPU的芯片，至少要用Canary。别指望编译器自带的栈保护选项——它们只能检测部分溢出情况。

知识结构总览

下面这张图把栈的核心知识点串起来了。你可以把它当作调试时的"检查清单"。