obj-copy игнорирует некоторые отступы

Столкнулся со странной проблемой в манипуляторе 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 = .;

person ria    schedule 13.09.2018    source источник
comment
есть несколько статей об этом ALIGN на gnu плохо, он зависит от архитектуры (имеется в виду x86 он делает одно, мипит другое, вооружает другое), но BALIGN (конечно, для сборки хотелось бы надеяться на скрипты компоновщика) немного более очевиден и последовательно по целям.   -  person old_timer    schedule 13.09.2018
comment
Я уверен, что это не ошибка, но вместо этого он работает так, как работает, и люди к этому привыкают.   -  person old_timer    schedule 13.09.2018
comment
И меня ничуть не удивит, если ассемблер gnu и компоновщик gnu (обе части binutils) используют ALIGN по-разному.   -  person old_timer    schedule 13.09.2018
comment
Вы можете попробовать .balign или использовать .fill ALIGN(0x1000) : {}. Я думаю, что вы можете даже не включать .fill в раздел вывода изображения. Убедитесь, что вы обозначили .fill как выделенный раздел. В противном случае он может не попасть в двоичный файл. Создайте файл карты, чтобы убедиться, как он расположен/распределен.   -  person artless noise    schedule 13.09.2018
comment
BALIGN выдал мне синтаксическую ошибку при сборке   -  person ria    schedule 14.09.2018
comment
Вы создали файл карты и посмотрели на него? ld не очень удобен для пользователя, но настоящие ошибки встречаются редко. Я много раз думал, что были ошибки, но обнаружил, что это какая-то странная проблема с синтаксисом (например, опечатка и т. Д.). Обязательно сгенерируйте файл карты и покажите здесь вывод для раздела из файла карты.   -  person artless noise    schedule 14.09.2018
comment
Я просмотрел шестнадцатеричный дамп своего изображения. Он был правильно заполнен (с нулями), когда я использовал, например. Выравнивание 0x20, 0x100 и 0x400. Но выравнивание 0x1000 дает тот же результат, что и 0x400. Я могу опубликовать файл карты, когда вернусь к работе.   -  person ria    schedule 14.09.2018
comment
Благодаря бесхитростному шуму, когда я проверил файл карты, я увидел, что сегмент .fill имеет правильный размер для заполнения до 0x1000.   -  person ria    schedule 18.09.2018


Ответы (1)


Я нашел ошибку, и она была моей. После оценки всех вычислений в моем скрипте компоновщика я обнаружил, что MEM_START имеет значение 0x905c00, из-за чего шестнадцатеричный дамп двоичного файла выглядит не выровненным в случае выравнивания 0x1000.

person ria    schedule 19.09.2018