GCC链接后获取各段精确大小的首选方法是使用arm-none-eabi-size -A firmware.elf，可直接输出.text、.data、.bss等段的原始字节大小；若需加载地址（LMA）与运行地址（VMA）差异等细节，则必须解析.map文件。
gcc链接后怎么拿到各段的精确大小（.text/.data/.bss）
ARM GCC默认不输出内存段分布报告，得靠链接器自己吐——关键是让ld在生成可执行文件/固件时顺便把段大小写进一个文件。最直接的办法是加-Wl,--print-memory-usage（GCC 10+ 支持），但老版本GCC（比如GNU Arm Embedded Toolchain 9-2019-q4-major）不认这个参数，得退回到ld原生命令。
推荐做法：在gcc命令末尾加-Wl,--map=output.map，生成map文件，再用arm-none-eabi-size或手动解析map看段分布。
-
arm-none-eabi-size -A <code>your_firmware.elf：按段列出.text、.data、.bss等原始大小，单位字节，最轻量 -
arm-none-eabi-size -t <code>your_firmware.elf：加-t会汇总总和，方便核对RAM/ROM占用是否超限 - 如果用了
--gc-sections，size结果可能比实际链接后小，因为丢弃的段不会出现在最终ELF里，但size只统计保留下来的段——这点常被忽略
map文件里怎么看真实加载地址和运行时地址差异
嵌入式常见场景：.data段从Flash加载（LOADADDR），但运行时要复制到RAM（VMA ≠ LMA）。光看size给的.data大小，没法知道它占多少Flash空间、又占多少RAM空间——得翻.map文件。
打开output.map，搜. = ORIGIN(RAM)或.data :这一节，你会看到类似：
立即学习“C++免费学习笔记（深入）”；
*(.data .data.*)
.data 0x20000000 0x400
0x00008000 . = ALIGN(0x4)
0x00008000 _sidata = LOADADDR(.data)
0x20000000 _sdata = .
这里0x00008000是LMA（Flash地址），0x20000000是VMA（RAM地址），0x400才是.data实际长度。所以：Flash多占0x400字节，RAM也多占0x400字节（不含copy代码本身）。
- 别只信
size输出的单一数值，尤其当.data或.bss有重定位时 -
.bss没有LMA（不存Flash），map里只显示VMA和大小，size输出的.bss值就是RAM净增大小 - 如果你用
__attribute__((section(".my_section")))自定义段，size -A会把它单独列出来，但map里才能看到它被塞到哪个内存区域里了
为什么arm-none-eabi-size有时显示0字节的.text
典型现象：arm-none-eabi-size -A firmware.elf 输出.text 0，但程序明明能跑——大概率是链接脚本里把代码段名字改了，比如写成.isr_vector、.code或.flash，而size默认只认标准段名。
- 运行
arm-none-eabi-readelf -S <code>firmware.elf，看所有段名列表，确认实际代码段叫什么 - 用
arm-none-eabi-size --format=SysV <code>firmware.elf，SysV格式会列出所有段（含非标名），比默认Berkeley格式更全 - 或者直接
arm-none-eabi-objdump -h <code>firmware.elf，看每个段的Size列，手动加总带可执行标志（AX）的段 - GCC链接时若用了
-ffunction-sections+--gc-sections，某些函数段可能被彻底删掉，导致对应段在ELF里消失——这时候size自然报0
自动化报告：一行命令导出CSV供Excel分析
做量产或CI检查时，需要把每次构建的段大小记下来比对。可以写个简单shell一行流：
arm-none-eabi-size -t -f firmware.elf | awk '/^\.text|^\.data|^\.bss|Total/ {printf "%s,%s\n", $1, $2}' > size_report.csv
注意-f启用“format”模式，让输出字段对齐，awk才好切；否则Berkeley格式空格不固定，容易错位。
- 如果项目用了多个内存域（如ITCM/DTCM/OCM），得先用
readelf -S找出对应段名，再针对性提取，不能只靠.text/.data - Windows下用MSYS2或WSL跑这条命令更稳，CMD里
awk行为可能不一致 - 真正卡资源的时候，往往不是
.text超了，而是链接脚本里留的stack/heap太小，或者.bss里某个大数组没用static限定——这些在size报告里看不到，得结合nm --size-sort查大符号
map文件永远比size命令多一层真相，但解析成本高；size快但默认视野窄。选哪个，取决于你现在卡在哪个环节：是快速过线检查，还是深挖某段为何突然涨了2KB。
