Я столкнулся со странной проблемой в obj-copy arm. Я что-то делаю не так или обнаружил ошибку?
Я хочу заполнить свое изображение нулями до выравнивания 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
Objdump:
.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 = .;
Я уверен, что это не ошибка, но он работает так, как работает, и люди к этому привыкают.
И меня ничуть не удивит, если ассемблер gnu и компоновщик gnu (обе части binutils) будут использовать ALIGN по-разному.
Вы можете попробовать .balign
или использовать .fill ALIGN(0x1000) : {}
. Я думаю, что вы могли бы даже не включать .fill
в выходной раздел образа. Убедитесь, что вы обозначили .fill
как выделенный раздел. В противном случае он может не попасть в двоичный файл. Создайте файл карты, чтобы убедиться, как он расположен / размещен.
BALIGN дал мне синтаксическую ошибку при сборке
Вы создали файл карты и просмотрели его? ld
не очень удобен для пользователя, но действительно ошибки встречаются редко. Я много раз думал об ошибках, но обнаружил, что это какая-то странная проблема с синтаксисом (например, опечатка и т. д.). Определенно создайте файл карты и покажите вывод для раздела здесь из файла карты.
Я просмотрел шестнадцатеричный дамп моего изображения. Он был правильно заполнен (с нулями), когда я использовал, например, Выравнивание 0x20, 0x100 и 0x400. Но алигент 0x1000 дает тот же результат, что и 0x400. Я могу опубликовать файл карты, когда вернусь к работе.
Спасибо "безыскусному шуму", когда я проверил файл карты, я увидел, что сегмент .fill имеет правильный размер для заполнения до 0x1000.
Я нашел ошибку, и она моя. После оценки всех вычислений в моем скрипте компоновщика я обнаружил, что MEM_START был 0x905c00, что сделало шестнадцатеричный дамп двоичного файла не выровненным в случае выравнивания 0x1000.
есть несколько статей об этом ALIGN на gnu - это плохо, это зависит от архитектуры (это означает, что x86 он делает одно, mips другое, вооружает другое), но BALIGN (конечно, для сборки можно надеяться на сценарии компоновщика) немного более очевиден и единообразно по целям.