Linker 产生巨大的输出二进制文件

我正在为飞思卡尔iMX6板开发小型hello world应用程序，该应用程序将从片内RAM运行。我能够从OCRAM运行完整的代码，但如果我修改链接器脚本以在外部DDR ram的内存空间中生成数据段，输出二进制文件的大小会突然从114 KB增加到259 MB。如果该部分是在OCRAM中创建的，它就可以正常工作。这肯定与链接有关，但我找不到原因以及如何避免它。以下是从链接器脚本中选择的部分：

`MEMORY
{
    OCRAM (rwx) : ORIGIN = 0x00900000, LENGTH = 256K
    DDR (rwx)   : ORIGIN = 0x10000000, LENGTH = 2048M
}`

.
.
.

.ex_ram（源（DDR））：
{
.=.+0x10；
}>DDR

---

在我看来，这似乎与OCRAM和DDR ram地址空间之间的巨大差距有关，但无法纠正它

当然可以，您要求它将文件转换为二进制文件，对吗？因此，即使您在数据段中只有一个字节的数据，您也需要在.bin文件中有（0x10000000-0x00900000）+（数据量）字节…原始二进制文件格式没有任何地址信息，因此它需要覆盖所有可加载的段，并在其间填充填充，这样您就得到了文件的大小（0x10000000-0x00900000）+（数据量）。做一个实验，将0x10000000更改为0x20000000，您将看到一个大小超过两倍的文件

---

如果您使用elf或coff、intel hex或srec或包含地址和数据的某种二进制格式，并且不需要在文件中的段之间填充，那么您的文件将保持较小…

这也是我的猜测，但提供的链接器文件包含OCRAM和DDR ram的部分，输出的二进制文件仍然是常规大小，即113kb。建议使用其他图像格式。然而，对于一些事情，如初始引导代码，这可能是不可能的。如果OP（或任何人）正在使用u-boot等，那么切换图像格式是一个简单的解决方案。经过仔细比较，我找到了使用原始链接器脚本创建较小bin文件的原因。原始链接器脚本在OCRAM中不加载任何内容。它简单地分为三个部分，没有加载，因此没有数据进入它们。二进制文件必须只处理DDR部分中的数据，因此大小较小@artlessnoise我使用的是裸机SDK，而制造工具（图像下载器）似乎不支持elf格式。看起来我必须使用“at”或指针，并从C语言开始使用。对于这个问题有各种各样的解决方案。查看

at

命令以及LMA和VMA的概念。我猜您需要在启动时将代码从DDR复制到OCRAM，因为OCRAM是有限的。正如dwelch所指出的，二进制文件必须是一个实心块。初始加载程序将OCRAM代码从加载DDR位置复制到运行VMA位置。这是减少二进制文件大小的标准方法，其中代码从不同的内存设备运行。未分配的部分，如

BSS

（即零内存）不会创建输出，也不会增加大小。@artlessnoise的可能重复我发现上述问题的范围更广，有些不同。我的问题非常具体。尽管如此，你的第一条评论（以及其他一些帖子）还是很有帮助的，但不是上面提到的问题。我根本不想使用外部RAM，因为我的例程最终会测试外部RAM的布线错误（并且我会在PCB布线中引入错误来测试我的例程）。也许你理解这一点，但天真的噪音告诉你的是，你可以拥有单独的段，但你不能告诉链接器“这里是它在内存空间中的位置”和单独的“这里是你把它放在二进制文件中的位置”，然后使用链接器变量和引导时间内存拷贝，在启动C（或更高级别的语言）之前，你将数据从二进制文件位置移到它的最终/正确的主位置代码。通过这种方式，二进制文件要小得多，因为填充被删除了，但总体结果是相同的减去一些复制时间。我认为现在我可以直接从OCRAM运行代码，而无需复制，因为我不信任外部RAM（当我自己产生接线错误时，我怎么能信任它）.同时，为了测试它，我可以将变量存储在外部RAM中，而不会像地狱一样增加二进制文件，也不会在链接器脚本中限制整个特定于地址的信息。谢谢大家！