3. 内存剖析工具链：GCC编译选项、Map文件分析、objdump与size命令实战
做嵌入式TLS握手优化，第一步不是改代码，而是搞清楚内存到底用在哪了。我见过太多人上来就调参数，结果折腾半天发现是堆栈配小了——这种坑，踩一次就够了。
这一章，咱们把工具链捋一遍。说白了，就是学会怎么让编译器告诉你内存的底细。
3.1 GCC编译选项：让编译器开口说话
GCC默认是沉默的。你得给它几个关键选项，它才会把内存布局的细节吐出来。
核心选项清单
-ffunction-sections：每个函数独立成段。没有这个，链接器没法精准裁剪。-fdata-sections：每个全局/静态变量独立成段。道理同上。-Wl,--gc-sections：链接时干掉没被引用的段。这是瘦身的关键一步。-Wl,-Map=output.map：生成Map文件。没有它，你就是在盲人摸象。
我个人习惯在Makefile里这样写：
CFLAGS += -ffunction-sections -fdata-sections
LDFLAGS += -Wl,--gc-sections -Wl,-Map=$(TARGET).map
嗯，这里要注意：--gc-sections 依赖前面的 -ffunction-sections 和 -fdata-sections。少一个，裁剪效果就大打折扣。
小技巧：调试阶段可以加 -g 保留调试信息，但发布版本务必去掉。我见过有人把带调试符号的固件直接烧到量产设备里——Flash直接爆了。
3.2 Map文件分析：内存布局的X光片
Map文件是链接器给你的一张详细清单。它记录了每个段、每个符号的地址和大小。说白了，这就是你固件的内存CT扫描结果。
我曾经接手过一个项目，TLS握手总是随机失败。打开Map文件一看，堆栈段紧挨着一个大数组，数组越界直接踩了栈空间——这种问题，看代码很难发现，但Map文件里一目了然。
3.2.1 Map文件结构速览
一个典型的Map文件包含这几部分：
| 区域 | 内容 | 关注点 |
|---|---|---|
| Archive member included | 链接了哪些库文件 | 检查是否有不必要的库被拉进来 |
| Linker script and memory map | 各段的起始地址、大小、对齐 | 重点关注 .text, .data, .bss, .heap, .stack |
| Cross Reference Table | 符号引用关系 | 排查未使用的符号 |
我最常看的是第二部分。直接搜 .text、.bss、.data 就能定位到关键信息。
3.2.2 实战：揪出内存大户
假设你的Map文件里有这么一段：
.text 0x08002000 0x1a3c
0x08002000 _stext
0x08002000 _startup
0x08002004 main
0x080020a0 mbedtls_ssl_handshake
0x08002210 mbedtls_ssl_write
0x08002380 mbedtls_ssl_read
0x080024f0 mbedtls_ssl_handshake_step
0x08002600 mbedtls_ssl_handshake_wrapper
看到没？mbedtls_ssl_handshake 占了 0x170 字节（从 0x080020a0 到 0x08002210）。如果这个函数在握手完成后不再需要，就可以考虑把它放到可回收的内存区域。
避坑指南：我曾经在Map文件里看到一个全局缓冲区占了8KB，代码里却只用了前256字节。这种浪费，Map文件一眼就能揪出来。别光看代码，Map文件才是真相。
3.3 objdump：反汇编与段信息
objdump 是个多面手。我主要用它做两件事：看段头信息和反汇编验证。
3.3.1 查看段信息
arm-none-eabi-objdump -h firmware.elf
输出示例：
Sections:
Idx Name Size VMA LMA File off Algn
0 .text 00001a3c 08002000 08002000 00010000 2**2
1 .data 00000200 20000000 08003a3c 00020000 2**3
2 .bss 00000400 20000200 20000200 00020200 2**3
3 .stack 00001000 20001000 20001000 00000000 2**3
这里 VMA 是运行时地址，LMA 是加载地址。对于 .data 段，两者不同意味着启动代码需要做拷贝——这部分开销也要算进内存优化里。
3.3.2 反汇编验证
有时候编译器优化会做一些你意想不到的事。比如你写了个 memset 清空缓冲区，结果编译器觉得没必要直接跳过了——这种bug，反汇编一看就明白。
arm-none-eabi-objdump -d firmware.elf > disasm.txt
然后搜你的函数名，逐行比对汇编。我一般只看关键函数的开头和结尾，确认栈帧分配和寄存器保存是否符合预期。
个人经验：用 objdump -S 可以混排源码和汇编，调试时特别有用。但发布版本建议只用 -d，避免源码路径泄露。
3.4 size命令：快速体检
size 是最快的体检工具。一行命令，三段数据：
arm-none-eabi-size firmware.elf
text data bss dec hex filename
0x1a3c 0x0200 0x0400 0x203c 0x203c firmware.elf
这三个数字的含义：
- text：代码段 + 只读常量。这部分通常存在Flash里。
- data：已初始化的全局/静态变量。运行时在RAM，但初始值存在Flash。
- bss：未初始化的全局/静态变量。运行时在RAM，不占Flash空间。
你想想看，如果 bss 比 text 还大，那大概率是某个地方定义了大数组。我遇到过有人把证书缓冲区定义成全局变量，结果bss直接飙到几十KB——其实完全可以用堆分配，握手完就释放。
优化目标参考：对于受限设备（比如Cortex-M0+，64KB Flash，16KB RAM），TLS握手相关代码建议控制在：
- text：不超过8KB
- data：不超过1KB
- bss：不超过2KB
- 堆栈：总共不超过4KB
超过这个范围，你就得认真考虑裁剪了。
3.5 工具链协同工作流
这几个工具不是孤立的。我一般按这个流程走：
- size 快速扫描：看一眼整体分布，心里有个数。
- Map 文件细查：定位具体是哪个函数或变量占了大头。
- objdump 验证：确认编译器没有做奇怪的优化。
- 调整编译选项：比如加
-Os优化尺寸，或者用-fdata-sections配合--gc-sections裁剪。 - 重复步骤1-4：直到内存占用符合预期。
下面这张图把这个流程串起来了：
3.6 实战案例：一次TLS握手内存优化
说个真实案例。之前有个项目，MCU只有32KB RAM，TLS握手库一链接，bss直接占了18KB。用size一看：
text data bss dec hex
0x4a00 0x0800 0x4800 0x9a00 0x9a00
bss 18KB，这显然有问题。打开Map文件，发现 mbedtls_ssl_session 结构体里有个 peer_cert 缓冲区，默认配了8KB。但我们的场景根本不需要证书——用的是PSK模式。
于是做了两件事：
- 在
mbedtls_config.h里关掉MBEDTLS_SSL_KEEP_PEER_CERTIFICATE。 - 把
MBEDTLS_SSL_MAX_CONTENT_LEN从16KB降到4KB。
重新编译，size结果：
text data bss dec hex
0x3c00 0x0600 0x0c00 0x4e00 0x4e00
bss从18KB降到了3KB。你看，有时候优化就是这么直接——找到那个最肥的变量，一刀下去。
注意：改这些宏定义之前，一定要确认你的TLS握手流程确实不需要那么大缓冲区。我曾经为了省内存把 MAX_CONTENT_LEN 改太小，结果握手到一半直接报 MBEDTLS_ERR_SSL_BUFFER_TOO_SMALL——那个错误码我到现在都记得。
3.7 本章小结
工具链是内存优化的眼睛。size帮你快速定位问题规模，Map文件告诉你问题在哪，objdump帮你验证修改是否正确。这三板斧用熟了，大部分内存问题都能在半小时内定位。