bug-binutils
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

readelf assume section headers are always 40 bytes long


From: Gilles Mouchard
Subject: readelf assume section headers are always 40 bytes long
Date: Thu, 01 Apr 2004 17:54:22 +0200
User-agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030630

Hi,

readelf from package binutils-2.14.90.0.5-2mdk incorrectly assumes that struct Elf32_Shdr is 40 bytes, i.e sizeof(Elf32_Shdr), even if it displays on the screen the good value for the section header size.
The real size of the structure is in field e_shentsize of struct Elf32_Ehdr.
The bug make readelf incorrectly walk across the section header table which follows the ELF header.

This bugs appears with my ELF files generated with VisualDSP++ 3.0 from Analog Device which generates ELF files with 44-bytes section headers. The output of readelf follows:

$ readelf -a test.dxe

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:                              <unknown>: 8
  Machine:                           <unknown>: 1c
  Version:                           0x1
  Entry point address:               0x0
  Start of program headers:          0 (bytes into file)
  Start of section headers:          13432 (bytes into file)
  Flags:                             0xc
  Size of this header:               52 (bytes)
  Size of program headers:           0 (bytes)
  Number of program headers:         0
  Size of section headers:           44 (bytes)
  Number of section headers:         15
  Section header string table index: 1

Section Headers:
  [Nr] Name              Type            Addr     Off    Size   ES Flg Lk Inf Al
  [ 0] ELF           NULL            00000000 000000 000000 00      0   0  0
  [ 1] ELF           PROGBITS        00000000 000000 000034 00  WA 2850   0  0
  [ 2] ELF           NULL            00000002 000000 000000 01  Ax 2902 d34  1
  [ 3] ELF           <unknown>: 14   00000013 000001 02042e 00     262144 188a 978
  [ 4] ELF           PROGBITS        00000000 00001c 000001 36   W 132138 40100 7260
  [ 5] ELF           NULL            00000001 000000 000026 00   W  0 428  0
  [ 6] ELF           NULL            00000000 000001 000000 40288     52   1 132142
  [ 7] <corrupt>         <unknown>: 83a  00000000 000001 000001 128      0  3e  0
  [ 8] ELF           NULL            00000000 000000 000000 01      1   0 72
  [ 9] <corrupt>         <unknown>: 5000 00000618 000000 000000 52 XxILTx  1   1  0
  [10]                   <unknown>: 130  00002ae4 000000 000000 00      0   0  1
  [11] <corrupt>         NOBITS          00000000 002ae4 000000 01 MSO  0   0  0
  [12] ELF           <unknown>: 62   00000000 000000 000000 00      0   0  0
  [13] ELF            NULL            0000000e 000000 000000 00 XMSI 10980   4  1
  [14] ELF            RELA            000000df 00000d 000000 01      0 2ae8 192
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 program headers 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.


Best regards,
Gilles Mouchard


reply via email to

[Prev in Thread] Current Thread [Next in Thread]