ELF 与bin文件不一致

如何解释下载到 MCU 的 ELF 文件与使用 objcopy 创建的二进制文件之间的不匹配？

使用 CubeProgrammer 从 MCU 中读回了程序代码，并与 .bin 文件进行了比较。

有两个方面的不匹配：

* 中断向量和 .text 之间的 8 字节填充。

* 多个字节的不一样。所有这些字节都加载为 5C，

比较文件 read-out.bin 和 foo.bin

........................

0000AD10： 5C 2F

0000AD14： 5C 2F

0000AD18： 5C 2F

0000AD22： 5C 2F

0000AD2D： 5C 2F

0000AD3D： 5C 2F

0000AD45： 5C 2F

0000AD5A： 5C 2F

0000AD5E： 5C 2F

0000AD78： 5C 2F

0000AD7C： 5C 2F

0000AD80： 5C 2F

........

0000B339： 5C 2F

0000B34E： 5C 2F

0000B352：5C 2F

在映射文件中，这些字节位于 C 函数的 .rodata 部分中：

.rodata        0x000000000802acc8       0x46 Core/Src/main.o *fill*         0x000000000802ad0e        0x2  .rodata        0x000000000802ad10       0x66 Drivers/STM32H7xx_HAL_Driver/stm32h7xx_hal_cortex.o *fill*         0x000000000802ad76        0x2  .rodata        0x000000000802ad78       0x63 Drivers/STM32H7xx_HAL_Driver/stm32h7xx_hal_crc.o *fill*         0x000000000802addb        0x1  .rodata        0x000000000802addc       0x66 Drivers/STM32H7xx_HAL_Driver/stm32h7xx_hal_crc_ex.o

为什么这些字节会有不同？

我之前也碰到过类似情况，用 CubeProgrammer 读出来的 bin 总是多出些奇怪的值……最后发现是链接脚本里填充段的问题。你链接文件能贴一下吗？

会不会是 objcopy 把某些填充的段优化掉了？你试试加 --pad-to 或 --gap-fill 参数看有没有差别。

5C 这个值很可疑，有点像某种保留字节或者初始化默认值？可能是编译器或者链接器自动填的。

看你列出的地址，刚好落在 .rodata 这些只读段中，估计和对齐或者填充有关。我猜 read-out 的是 MCU 真正烧录进去的内容，但 objcopy 会省略空洞。

你是不是用的是 H7？我记得 H7 有些 cache 或 AXI bus 的行为会影响 Flash 的填充，有可能会看到和 bin 文件不一致的情况。

有一种可能是 .bin 文件其实没有包含某些零散的段，而 MCU 中的 flash 区是按 32bit 填满的，所以读出来多了些 5C。

你可以试试用 .hex 文件代替 .bin，有时候 Intel Hex 会更完整地保留地址映射信息，拿它来对比说不定更准确。

中断向量和 .text 中间的 8 字节填充可能是因为链接时强制对齐到了某个边界，Flash 的地址对齐规则有时候比较挑。

我遇到过这种情况最后是 map 文件救了我，把两个地址一对照，发现 bin 文件其实缺了一些填充段，objcopy 默认会跳过。

建议你用 readelf -S 和 objdump -h 看下 ELF 的段布局，再和 bin 一比对，就能发现哪些段被落下了，基本都能对上。