когда вы используете -O двоичный файл, вы в значительной степени отказываетесь от .text, .data..bss control.Например, если у вас есть одно слово 0x12345678 по адресу 0x10000000, вызовите этот .text и одно слово .data по адресу 0x20000000, 0xAABBCCDD, и вы используете -O-двоичный файл, вы получите файл длиной 0x10000004 байта, который начинается с 0x12345678 и заканчивается 0xAABBCCDDи имеет 0x0FFFFFFC байтов нулей.попробуйте выгрузить это в чип, и вы можете стереть ваш загрузчик (uboot и т. д.) или уничтожить кучу регистров и т. д., не говоря уже о работе с потенциально огромными файлами и вечностью для передачи на плату в зависимости от того, как вы намереваетесьсделать это.
То, что вы можете сделать, что типично для загрузчиков на основе rom, - это использовать gcc tools
MEMORY
{
bob : ORIGIN = 0x10000000, LENGTH = 16K
ted : ORIGIN = 0x20000000, LENGTH = 16K
}
SECTIONS
{
.text : { *(.text*) } > bob
.bss : { *(.bss*) } > ted AT > bob
.data : { *(.data*) } > ted AT > bob
}
Код (.text) будет связан, как если бы .bss и.data находятся на своих местах в памяти, 0x20000000, но байты загружаются исполняемым файлом (загрузчик elf или двоичный файл -O и т. д.), прикрепленным к концу .text.Обычно вы используете больше магии линкерскрипта, чтобы определить, где линкер сделал это.При загрузке ваш .text-код должен сначала обнулить .bss и скопировать .data из пространства .text в пространство .data, а затем вы сможете нормально работать.
uboot, вероятно, может обрабатывать форматы, отличные от .binда?Также довольно просто написать инструмент elf, который извлекает различные части двоичных файлов и создает ваши собственные .bins, не используя objcopy.Также довольно легко написать код, который никогда не полагается на ноль .bss и не имеет данных .data.решение всех этих проблем.