Добавить ресурсы в объект ELF, сгруппированный в один раздел

Question

Небольшая программа, которую я сделал, содержит множество небольших растровых изображений и звуковых клипов, которые я бы предпочел включить в сам двоичный файл (они должны быть отображены в памяти в любом случае). В стандарте MS PE/COFF существует конкретное описание того, как включать ресурсы (раздел .rsrc), который имеет хорошую иерархию файловой системы. Я не нашел ничего подобного в спецификации ELF для Linux, поэтому я предполагаю, что можно свободно включать эти ресурсы, как казалось нужным.

Что я хочу достичь, так это то, что я могу включить все ресурсы только в один раздел ELF с символическим именем в начале каждого ресурса (чтобы я мог обращаться к ним из своего кода на C). То, что я делаю сейчас, используя небольшой NASM файл, который имеет следующую структуру:

SECTION .rsrc 
    _resource_1: 
     incbin "../rsrc/file_name_1" 
    _resource_1_length: 
     dw $-resource_1 
    _resource_2: 
     incbin "../rsrc/file_name_2" 
    _resource_2_length: 
     dw $-resource_2 
    ... 

Я могу легко собрать это объект ELF, который может быть связан с моим кодом C. Тем не менее, мне не нравится использование сборки, поскольку это делает мой код зависимым от платформы.

Что было бы лучшим способом добиться того же результата?

Этот вопрос уже задавался на StackOverflow, но предлагаемые решения не применимы к моему делу:

• Решение, предложенное здесь: C/C++ with GCC: Statically add resource files to executable/library Включая ресурсы, как шестигранные массивы в коде C не очень полезно, поскольку это смешивает код и данные в одном разделе. (Кроме того, это тоже не практично, поскольку я не могу просмотреть ресурсы после их преобразования в массивы)
• Использование objcopy --add-section на каждом ресурсе работает, но затем каждый ресурс получает свой раздел (включая заголовок и все такое). Это кажется немного расточительным, поскольку у меня есть около 120 файлов для включения (каждый из +/- 4K).

Answer 1

Ошибаешься говорят, что использование hexarrays смешивает данные и код, как и ELF файлы будут разделить их по умолчанию, в частности, если вы определяете hexarray как константного массива, он будет в конечном итоге в .rodata. См. an old post of mine для получения дополнительной информации о .rodata.

Добавление ресурсов с помощью objcopy должно создавать несколько разделов в объектном файле, но затем все они должны быть объединены в выходной исполняемый файл, хотя тогда вы наверняка будете иметь дополнительное дополнение. Another post on a related topic.

Ваш альтернативный вариант, если вы хотите перейти от фактического бинарного файла (скажем, PNG) к ELF, вы можете использовать ldscripts, что позволяет вам создавать файлы ELF с произвольными разделами/символами и считывать данные из файлов. Вам все равно понадобятся специальные правила для создания вашего файла ELF.

На самом деле я удивлен, что такое управление ресурсами больше не используется для ELF, тем более что для многих небольших файлов это улучшит производительность файловой системы довольно быстро, так как тогда у вас есть только один файл для сопоставления, а не многие.

Answer 2

Если ваш ресурс не слишком велик, вы можете перевести его в исходный код C/C++, например, в качестве массива unsigned char. Затем вы можете получить к ним доступ в виде глобальных переменных, а компиляция & связывает их, как с обычным исходным кодом.