嵌入式软件只做静态堆栈分析,还不够呀?

正文

大家好，我是bug菌~

到了一年一度的公司风向标会议，各种做调研、做方案、做报告，那是忙得一个不可开交，其中各个部门提得最多的还是AI在部门工作中的加持下所预计会带来的收益，但是也是想了下既然大家都提AI那我就写一个关于AI安全相关的主题来展开吧，其实每年都加都提了非常多的方案和所谓的风口，不过都推进得非常缓慢，这会议就当做公司的仪式感吧。

那么这篇文章呢不是谈AI，还是开发中的一些小思考吧，玩C或者C++都离不开对堆栈的理解，那么堆栈究竟要配置多大其实一直也是一个经验性的问题，堆栈小了导致所谓的"爆栈"溢出引发 HardFault、随机死机，栈太大了又会资源增加成本。所以你特别像知道你的嵌入式程序每个人物所需要的最大堆栈是多少，然后在最大堆栈的基础上预留一点点就可以了。

然而大部分的工具都只能分析编译后拿到静态的堆栈使用数据，而无法知道程序运行起来真实的堆栈消耗，那这不就矛盾了吗？

好吧，一步一步来，我们先看看堆栈的静态分析都干了些啥：

堆栈静态分析

当我们的嵌入式程序还没有运行的时候，我们能拿到的无非是程序的源码、函数的调用关系、编译后的二进制，当然这里面也包含对堆栈的操作。

有了这些信息的话，静态堆栈分析就能去做一些事情了，最直接的就是单函数栈帧的计算，编译器可以准确计算出每个独立函数的栈帧大小，这部分是完全确定的：

函数内的局部变量、数组、结构体的总大小
函数调用时需要保存的 CPU 寄存器（如 ARM Cortex-M 的 R4-R11 等）
函数参数、返回地址的存储开销
栈对齐所需的填充字节

比如 GCC 编译器提供的-fstack-usage选项,GCC会为每个编译单元（.c / .cpp）生成一个对应的 .su 文件（Stack Usage 文件）。该文件记录了该编译单元内每一个函数的堆栈帧大小信息,类似于这样的格式：

其实这里的：

static 表示函数的堆栈帧大小完全在编译时确定，全部是静态分配的局部变量、保存的寄存器、参数区域等。

dynamic 表示函数中使用了运行时动态栈分配，比如 alloca 或可变长度数组（VLA），因此报告中的数值只包含静态部分，实际运行时会动态增加。

当然前面只是简单的单函数栈帧的分析，相对全面一点是静态调用图的理论栈深估算。

静态分析工具会扫描所有确定的函数调用关系，构建调用树（Call Graph），然后找到最深的那条调用路径，把路径上所有函数的栈帧大小累加起来，得到一个理论上的最大栈深。

比如 IAR、Keil 等 IDE 的静态栈分析功能，就是通过这个逻辑，在 map 文件中输出类似这样的报告：

**************************************************************************** STACK USAGE***Call Graph Root Category Max Use Total Use------------------------ ------- ---------Program entry 288 288Maximum call chain 288 bytes"__iar_program_start" 4"_main" 8"_printf" 8"__PrintfFullNoMb" 152"__LdtobFullNoMb" 80