2012-11-21 48 views
0

我有一個工具發出一個ELF,據我所知它符合規範。 Readelf輸出看起來很好,但objdump拒絕反彙編任何東西。objdump將不會顯示我的ELF部分

我已經簡化了輸入到一個單一的全局變量,並且「int main(void){return 0;}」來幫助調試 - 微小的段大小是正確的。

尤其objdump的似乎無法找到部分表:

$ 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 

$ 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,來自完全相同的對象構建,只能用普通工具鏈使用產生即使我從'known good'內核中剝離了.comment和.ARM.attributes部分(因爲objdump需要它們),它仍然很高興地列出了那裏的部分,但是並沒有在我的工具davidm.elf中列出。

我已經確認這兩節的內容與readelf -x是相同的。

我唯一能想象的是ELF文件的佈局是不同的,打破了BFD的一些期望,這可以解釋爲什麼readelf(和我的工具)處理它很好,但objdump有麻煩。

完全readelf:

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期望,記錄或其他方面的某些字節流對齊限制?

最後 - 這個文件不打算被映射到一個地址空間,加載器會將memcpy段的數據放到所需的位置,所以不需要播放mmap友好的文件對齊技巧。保持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 
+0

你能上傳壞比較readelf輸出

感謝趕上這文件樣本?或者至少輸出'objdump -x'? –

+0

當然可以;原始Q用鏈接和「objdump -x」輸出更新。 –

回答

1

OK - 終於想通了。

在小測試應用程序的上下文中構建和註釋/調試libbfd(函數elf_object_p())之後,我發現它爲什麼不匹配任何BFD支持的目標。

我有部分標題的錯誤sh_type標誌:NULL。在適當的時候發射STRTAB或者PROGBITS(最終獲得NOBITS),objdump高興地走過我的形象。

沒有真正令人驚訝的,回想起來 - 我更惱火我沒有在比什麼都:(您的幫助所有:)