Столкнулся со странной проблемой в манипуляторе obj-copy. Я что-то не так делаю или наткнулся на баг?
Я хочу заполнить свое изображение нулями до выравнивания 0x1000 (4096), и я делаю это дополнение с помощью приведенного ниже скрипта ссылки. Проблема в том, что obj-copy не копирует весь отступ, а почему-то останавливается на 0x400.
Я использовал objdump для оценки своего раздела, и, похоже, он имеет правильный размер для заполнения до 0x1000.
Почему шестнадцатеричный дамп моего двоичного файла не заполняется правильно в случае использования заполнения 0x1000? Я использую objcopy следующим образом для создания своего двоичного файла:
/usr/local/armhf/r27/bin/arm-axis-eabi-objcopy -I elf32-little -O binary myobj.o myobj.bin
Образ дамп:
.fill 0000080c 009117f4 009117f4 000117f4 2**0
CONTENTS, ALLOC, LOAD, DATA
009117f4 l d .fill 00000000 .fill
00912000 g .fill 00000000 __Eloadimg
скрипт ссылки:
__Edata = .;
.fill :
{
FILL(0x00000000);
BYTE(0x00);
. = ALIGN(0x1000);
}
__Eloadimg = .;
.balign
или использовать.fill ALIGN(0x1000) : {}
. Я думаю, что вы можете даже не включать.fill
в раздел вывода изображения. Убедитесь, что вы обозначили.fill
как выделенный раздел. В противном случае он может не попасть в двоичный файл. Создайте файл карты, чтобы убедиться, как он расположен/распределен. - person artless noise   schedule 13.09.2018ld
не очень удобен для пользователя, но настоящие ошибки встречаются редко. Я много раз думал, что были ошибки, но обнаружил, что это какая-то странная проблема с синтаксисом (например, опечатка и т. Д.). Обязательно сгенерируйте файл карты и покажите здесь вывод для раздела из файла карты. - person artless noise   schedule 14.09.2018