linker - 当 VMA != LMA 时加载 ELF

Question

我对这个有问题。我使用 ARM Cortex-A9 和 DS-5 来创建裸机固件。我修改了我的链接器文件，故意将 .data 部分 LMA 与 text 和 Rodata 部分相邻，因为它的默认运行时 VMA 位于 1MB 之外，而 .bin 图像大约为 1MB，但包含 90% 的零。所以我特意制作了 LMA != VMA 以节省空间。我还在 start.S 中添加了一个代码，它将 .data 部分从它的 lma 重新定位到 vma。

然而，在 DS-5 中加载生成的 elf 文件时，它已经将所有部分加载到它们的 VMA。结果，我的 start.S 代码应该重新定位数据，从带有垃圾内容的 LMA 复制到已经正确的 VMA，不久之后这些垃圾导致了错误。

我在 Cortex-M4 中使用过二进制不相等的 VMA 和 LMA 的经验，并使用 gdb 进行 Sprite 调试，那里没有问题，但它是微 Controller 。在我当前的 arm 处理器应用程序中，我将如何在 elf 中模拟调试将数据从其 LMA 正确复制到 VMA 的场景。很可能在使用二进制格式独立启动时不会有任何问题，但现在我们仍在 elf 调试中，所以我必须解决这个问题。

Answer 1

问题解决了...我想分享给我的解决方案:

认识到“VMA”和“LMA”是 GNU 实用程序术语而不是 ELF 规范中的术语会有所帮助。一旦你开始通过解释 ELF 可执行文件来查看它，你会发现有一个名为“p_paddr”的程序头字段和另一个名为“p_vaddr”的字段——这使得搜索更容易!在 DS-5 中使用 p_paddr 所需的选项是:

ARM DS-5 调试器命令引用:1.3.138 set elf load-segments-at-p_paddr

默认情况下，DS-5 使用 p_vaddr，这是标准。 p_paddr 的使用是一种实现质量，并且在规范中非常松散地定义。 ARM 编译器、链接器和 C 库不会生成此信息，因为重定位过程是在内部处理的(分散加载)。有些环境使用 p_paddr 不是物理地址，而是加载地址(因此是“LMA”)，有些环境使用它作为地址来解析启用 MMU 之前和之后的符号。