objdump не показывает мои разделы ELF

Question

У меня есть инструмент, излучающий ELF, который, насколько я могу судить, соответствует спецификации. Вывод readelf выглядит нормально, но objdump отказывается что-либо разбирать.

Я упростил ввод для единственного глобального var и "int main(void) { return 0;}" для облегчения отладки - крошечные размеры разделов верны.

В частности, objdump не может найти таблицу разделов:

$ arm-none-linux-gnueabi-readelf -S davidm.elf 
There are 4 section headers, starting at offset 0x74:
Section Headers:
  [Nr] Name              Type            Addr     Off    Size   ES Flg Lk Inf Al
  [ 0]                   NULL            00000000 000000 000000 00      0   0  0
  [ 1] .text             NULL            ff000000 000034 00001c 00  AX  0   0  4
  [ 2] .data             NULL            ff00001c 000050 000004 00  WA  0   0  4
  [ 3] .shstrtab         NULL            00000000 000114 000017 00      0   0  0

$ arm-none-linux-gnueabi-objdump -h davidm.elf 
davidm.elf:     file format elf32-littlearm
Sections:
Idx Name          Size      VMA       LMA       File off  Algn

У меня также есть еще один ELF, построенный из точно таких же объектов, который создается только при регулярном использовании набора инструментов:

$ objdump -h kernel.elf 

kernel.elf:     file format elf32-littlearm

Sections:
Idx Name          Size      VMA       LMA       File off  Algn
  0 .text         0000001c  ff000000  ff000000  00008000  2**2
                  CONTENTS, ALLOC, LOAD, READONLY, CODE
  1 .data         00000004  ff00001c  ff00001c  0000801c  2**2
                  CONTENTS, ALLOC, LOAD, DATA

Даже после того, как я удалил разделы.comment и.ARM.attributes (в случае, если их требует objdump) из "известного хорошего" файла kernel.elf, он все равно с удовольствием перечисляет разделы там, но не в davidm.elf моего инструмента.

Я подтвердил, что содержимое разделов идентично между двумя с readelf -x.

Единственное, что я могу изобразить, это то, что формат файла ELF отличается и нарушает некоторые ожидания BFD, что может объяснить, почему readelf (и мой инструмент) обрабатывает его так хорошо, но у objdump есть проблемы.

Полный перевод:

ELF Header:
  Magic:   7f 45 4c 46 01 01 01 00 00 00 00 00 00 00 00 00 
  Class:                             ELF32
  Data:                              2's complement, little endian
  Version:                           1 (current)
  OS/ABI:                            UNIX - System V
  ABI Version:                       0
  Type:                              EXEC (Executable file)
  Machine:                           ARM
  Version:                           0x1
  Entry point address:               0xff000000
  Start of program headers:          84 (bytes into file)
  Start of section headers:          116 (bytes into file)
  Flags:                             0x5000002, has entry point, Version5 EABI
  Size of this header:               52 (bytes)
  Size of program headers:           32 (bytes)
  Number of program headers:         1
  Size of section headers:           40 (bytes)
  Number of section headers:         4
  Section header string table index: 3

Section Headers:
  [Nr] Name              Type            Addr     Off    Size   ES Flg Lk Inf Al
  [ 0]                   NULL            00000000 000000 000000 00      0   0  0
  [ 1] .text             NULL            ff000000 000034 00001c 00  AX  0   0  4
  [ 2] .data             NULL            ff00001c 000050 000004 00  WA  0   0  4
  [ 3] .shstrtab         NULL            00000000 000114 000017 00      0   0  0
Key to Flags:
  W (write), A (alloc), X (execute), M (merge), S (strings)
  I (info), L (link order), G (group), x (unknown)
  O (extra OS processing required) o (OS specific), p (processor specific)

There are no section groups in this file.

Program Headers:
  Type           Offset   VirtAddr   PhysAddr   FileSiz MemSiz  Flg Align
  LOAD           0x000034 0xff000000 0xff000000 0x00020 0x00020 RWE 0x8000

 Section to Segment mapping:
  Segment Sections...
   00     .text .data 

There is no dynamic section in this file.

There are no relocations in this file.

There are no unwind sections in this file.

No version information found in this file.

Может ли агрессивная упаковка макета на диске вызывать проблемы? Нарушаю ли я какие-либо ограничения на выравнивание байтового потока, которые BFD ожидает, документирует или нет?

Наконец, этот файл не предназначен для mmap-размещения в адресном пространстве, загрузчик будет сегментировать данные в нужном месте, поэтому нет необходимости использовать mmap-friendly трюки для выравнивания файлов. Хранение ELF маленьким является более важным.

Ура, DavidM

РЕДАКТИРОВАТЬ: меня попросили загрузить файл и / или предоставить "objdump -x". Итак, я сделал оба: davidm.elf

$ objdump -x davidm.elf 

davidm.elf:     file format elf32-littlearm
davidm.elf
architecture: arm, flags 0x00000002:
EXEC_P
start address 0xff000000

Program Header:
    LOAD off    0x00000034 vaddr 0xff000000 paddr 0xff000000 align 2**15
         filesz 0x00000020 memsz 0x00000020 flags rwx
private flags = 5000002: [Version5 EABI] [has entry point]

Sections:
Idx Name          Size      VMA       LMA       File off  Algn
SYMBOL TABLE:
no symbols

Answer 1

ОК - наконец-то разобрался.

После создания и аннотирования / отладки libbfd (функция elf_object_p()) в контексте небольшого тестового приложения я обнаружил, что оно не совпадает ни с одной из поддерживаемых BFD целей.

У меня были плохие флаги sh_type для заголовков разделов: NULL. Испускает STRTAB или PROGBITS (и, в конце концов, NOBITS, когда я захожу так далеко) в зависимости от обстоятельств, и objdump счастливо ходит по моему изображению.

Не очень удивительно, оглядываясь назад - я более раздражен, я не уловил этого при сравнении выводов readelf, чем все остальное:(

Спасибо за помощь всем:)