Сгенерированный двоичный файл из файла elf взрывается, если NOLOAD удален из раздела - PullRequest
Новая
       73

Сгенерированный двоичный файл из файла elf взрывается, если NOLOAD удален из раздела

1 голос
/ 13 марта 2019

У нас есть скрипт компоновщика с пользовательским разделом, который был добавлен по причинам, связанным с проверкой соответствия IEC.Однако после добавления этого раздела размер двоичного файла, созданного с помощью objcopy -O binary input output, увеличился с ~ 150 КБ до ~ 512 МБ.

Я проследил его до раздела, в котором отсутствует атрибут (NOLOAD).И я также могу несколько объяснить, почему двоичный файл был 512 Мбайт.

Наша память выглядит следующим образом: 

MEMORY
{
    rom    (rx)  : ORIGIN = 0x00000000, LENGTH = 0x00040000
    ram    (rwx) : ORIGIN = 0x20000000, LENGTH = 0x00007580

    CUSTOM_SECTION (rwx) : ORIGIN = 0x20000000, LENGTH = 0x00001000
}

Первоначально определен раздел: 

    CUSTOM_LOCATION:
    {
        CUSTOM_BEGIN = .;
        KEEP(*(CUSTOM_LOCATION));
        CUSTOM_END = .;

    } > CUSTOM_SECTION AT > ram

Если CUSTOM_LOCATION: заменен на CUSTOM_LOCATION (NOLOAD):, сгенерированный двоичный файл имеет нормальный формат.Без (NOLOAD) размер двоичного файла составляет ~ 512 Мбайт.

Я ищу причину, по которой этот двоичный файл становится таким большим.Что означает (NOLOAD) (или его отсутствие) для objcopy при создании бинарного файла?

Вторичный вопрос: в конце раздела мы говорим } > CUSTOM_SECTION AT > ram, можем ли мы обойтись без этой директивы?Можно ли его заменить на } > ram?(А можно ли удалить CUSTOM_SECTION из MEMORY части?

Я не видел различий в сгенерированном map файле

1 Ответ

1 голос
/ 13 марта 2019

Когда objcopy создает двоичный файл, он в основном выполняет ту же работу, что и загрузчик ELF ОС: он записывает загружаемые разделы ELF-файла в файл, представляющий память во время выполнения.

Двоичный файл будетсодержит каждый байт вашего кода и данных, от базового адреса до самого верхнего байта.Если образ памяти редок (есть области «ничего»), то двоичный файл также будет содержать большие области ничего.Это может быть представлено только в немом двоичном файле как нули.

Ваш файл эльфа содержит данные с адреса от 0x00000000 (основа ПЗУ) до 0x20000fff (верхняя часть CUSTOM_SECTION), что составляет диапазон чуть более500 МБ, поэтому понятно, что двоичный файл должен иметь столько байтов, чтобы вместить все это.Делая раздел не загружаемым, вы говорите, что данные не нужны во время выполнения и, следовательно, не должны быть в двоичном образе.Обычно это относится к отладочной информации, комментариям и другим непрограммным данным ELF.

Хорошей новостью является то, что a) многие файловые системы будут использовать дисковое пространство только для ненулевых частей файлапоэтому он не использует столько диска, сколько кажется («разреженный файл»), и б) двоичный файл будет легко сжимаемым.

...