2、静态内存分析：链接脚本(.lds)深度解析、代码段/数据段/BSS段布局优化、栈大小静态计算与配置
好，咱们进入第二个章节。静态内存分析，说白了就是你在编译完代码之后，还没跑起来之前，就能把内存怎么用算得清清楚楚。我见过太多工程师，程序跑飞了才回头查内存，那代价可就大了。今天咱们就把链接脚本、段布局、栈大小这几个硬骨头啃下来。
2.1 链接脚本(.lds)深度解析
链接脚本，很多人觉得它就是个编译工具链的附属品，不怎么在意。我个人习惯是，每接手一个新平台，第一件事就是把它的.lds文件从头到尾读一遍。为什么？因为它决定了你的程序在内存里怎么摆，摆错了，轻则性能下降，重则直接跑不起来。
一个典型的.lds文件长这样：
ENTRY(Reset_Handler)
MEMORY
{
FLASH (rx) : ORIGIN = 0x08000000, LENGTH = 512K
RAM (xrw) : ORIGIN = 0x20000000, LENGTH = 128K
}
SECTIONS
{
.text :
{
. = ALIGN(4);
*(.isr_vector)
*(.text)
*(.text*)
*(.rodata)
*(.rodata*)
. = ALIGN(4);
_etext = .;
} > FLASH
.data :
{
. = ALIGN(4);
_sdata = .;
*(.data)
*(.data*)
. = ALIGN(4);
_edata = .;
} > RAM AT> FLASH
.bss :
{
. = ALIGN(4);
_sbss = .;
*(.bss)
*(.bss*)
*(COMMON)
. = ALIGN(4);
_ebss = .;
} > RAM
}
这里有几个关键点，我重点说一下：
- MEMORY区域定义：FLASH和RAM的起始地址和大小，必须跟芯片手册一致。我遇到过有人把RAM长度写大了，结果链接时没报错，运行时直接踩到外设地址空间去了。
- 段定位：
.text放在FLASH里，.data和.bss放在RAM里。注意.data后面有个AT> FLASH，意思是它的加载地址在FLASH，运行地址在RAM。启动代码需要把这段数据从FLASH拷贝到RAM。 - 符号导出：像
_sdata、_edata这些符号，是给启动代码用的。我建议你给每个段都加上起始和结束符号，方便调试时查看内存使用情况。
.noinit，用来放那些掉电不需要重新初始化的数据。这样既能省去拷贝时间，又能保留上次运行的状态。
2.2 代码段/数据段/BSS段布局优化
段布局优化，说白了就是让代码和数据在内存里待得舒服，不打架。我做过一个项目，RAM只有64KB，但功能模块有十几个，每个模块都申请了一大堆全局变量。结果呢？BSS段直接爆了。
咱们一个一个来看：
2.2.1 代码段(.text)优化
代码段主要放的是你的指令和只读数据。优化思路其实很简单：
- 函数内联：把频繁调用的小函数改成内联，减少函数调用开销，但会增加代码体积。这是个权衡。
- 去掉调试符号：发布版本记得加
-s选项，能省不少空间。 - 使用短跳转：如果代码量不大，可以强制编译器生成短跳转指令，每条指令能省2个字节。
嗯，这里要注意，代码段优化不能过度。我曾经为了省空间，把所有函数都改成内联，结果代码膨胀了3倍，反而更慢了。
2.2.2 数据段(.data)优化
.data段放的是有初始值的全局变量和静态变量。优化点在于：
- 常量放到.rodata：如果变量在运行时不修改，用
const修饰，它会跑到只读数据段，不占RAM。 - 合并小数组：多个小数组如果能合并成一个结构体，能减少对齐浪费。
- 使用位域：对于状态标志位，用位域代替整型变量，一个字节能存8个标志。
| 优化前 | 优化后 | 节省空间 |
|---|---|---|
| uint8_t flag1, flag2, flag3, flag4; | struct { uint8_t f1:1; f2:1; f3:1; f4:1; } flags; | 3字节 |
| int buffer[100]; | short buffer[100]; (如果数值范围允许) | 200字节 |
2.2.3 BSS段优化
BSS段是未初始化的全局变量。这是内存消耗的大头，也是优化的重点区域。
我常用的几个方法：
- 动态分配代替静态数组：如果某个缓冲区只在特定函数里用，用
malloc或者栈上分配，别搞成全局的。 - 共用体(union)：多个互斥使用的变量，用union共享同一块内存。
- 延迟初始化：有些变量只在特定条件下才需要，别一股脑全在启动时分配。
2.3 栈大小静态计算与配置
栈大小这个问题，说简单也简单，说复杂也复杂。简单来说，栈就是用来存局部变量、函数参数和返回地址的。但具体多大才够？我见过有人拍脑袋设个1KB，结果递归调用深了就崩了。
静态计算栈大小，我一般分三步走：
- 列出所有函数调用路径：找出最深的调用链。比如A调用B，B调用C，C调用D，这就是4层。
- 计算每层栈帧大小：每个函数的局部变量、参数、返回地址加起来。可以用
objdump或者IDE的map文件查看。 - 加上中断嵌套：如果中断里也用了栈，要把最坏情况下的中断嵌套深度也算进去。
举个例子：
// 假设最深调用链：main -> task1 -> process_data -> compute
// 每层栈帧大小：
// main: 64字节
// task1: 128字节
// process_data: 256字节
// compute: 512字节
// 中断嵌套：假设最大嵌套2层，每层256字节
// 总栈需求 = 64 + 128 + 256 + 512 + 2*256 = 1472字节
// 加上安全余量20%：1472 * 1.2 ≈ 1766字节
// 实际配置：2KB
你可能会问，静态计算准不准？说实话，很难100%准确。因为编译器优化会影响栈帧大小，而且有些库函数的内部调用链我们看不到。所以我一般会在计算值的基础上加30%~50%的余量，然后在运行时用栈填充模式（比如0xDEADBEEF）来验证，看看实际用了多少。
嗯，说到验证，我建议你在启动代码里把栈区域全部填充成特定模式，然后在系统空闲时检查有多少被改写了。这样就能知道实际峰值栈使用量。我在一个项目中用这个方法发现，实际栈使用只有计算值的60%，后来就把栈从4KB减到了2KB，省下了2KB的RAM。
最后总结一下：静态内存分析不是一锤子买卖。链接脚本要反复调，段布局要持续优化，栈大小要验证再验证。你想想看，这些工作虽然繁琐，但做好了，系统稳定性直接上一个台阶。下一章咱们聊聊动态内存分配的那些坑，到时候见。