This is the mail archive of the ecos-devel@sourceware.org mailing list for the eCos project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: bug in RedBoot ELF loader?


On Tue, 2006-06-06 at 22:32 +0100, Bert Thomas wrote:
> > 
> > It means nonsense.
> > 
> > I do not agree that it's common for programs to include their ELF
> > header within the code.  A *long* time ago, things were structured
> > that way, but we've progressed quite a lot (since the 70's :-)
> 
> Up until now I have been unable to find a program that, according to 
> readelf, does not include the headers. If you do readelf on something on 
> your system, do the program segment headers specify an offset that skips 
> the headers themselves?

Of course - the headers are just that; descriptions of stuff to come
_later_ in the file.  A sane ELF file (files created by GNU ld behave
this way) will have the various section headers first, followed by
the actual program segments.  There is no need for a loader (like
RedBoot which is what started this discussion) to ever load the
headers as part of the image, rather only process them to figure
out what needs to be loaded and where.  For example, a RAM program
on my PowerPC system (suitable for loading with RedBoot) looks like
this:
[gthomas@hermes RAM]$ readelf -e install/bin/redboot.elf 
ELF Header:
  Magic:   7f 45 4c 46 01 02 01 00 00 00 00 00 00 00 00 00 
  Class:                             ELF32
  Data:                              2's complement, big endian
  Version:                           1 (current)
  OS/ABI:                            UNIX - System V
  ABI Version:                       0
  Type:                              EXEC (Executable file)
  Machine:                           PowerPC
  Version:                           0x1
  Entry point address:               0x80100
  Start of program headers:          52 (bytes into file)
  Start of section headers:          503664 (bytes into file)
  Flags:                             0x0
  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:         23
  Section header string table index: 20

Section Headers:
  [Nr] Name              Type            Addr     Off    Size   ES Flg Lk Inf Al
  [ 0]                   NULL            00000000 000000 000000 00      0   0  0
  [ 1] .vectors          PROGBITS        00080000 010000 001500 00  AX  0   0 256
  [ 2] .text             PROGBITS        00081500 011500 01be48 00  AX  0   0  4
  [ 3] .fini             PROGBITS        0009d348 034640 000000 00   W  0   0  1
  [ 4] .rodata1          PROGBITS        0009d348 034640 000000 00   W  0   0  1
  [ 5] .rodata           PROGBITS        0009d348 02d348 0058f0 00   A  0   0  4
  [ 6] .fixup            PROGBITS        000a2c38 034640 000000 00   W  0   0  1
  [ 7] .gcc_except_table PROGBITS        000a2c38 034640 000000 00   W  0   0  1
  [ 8] .data             PROGBITS        000a2c38 032c38 001a08 04 WAX  0   0  8
  [ 9] .sbss             NOBITS          000a4640 034640 0000a0 00  WA  0   0  4
  [10] .bss              NOBITS          000a46e0 034640 01db88 00  WA  0   0 32
  [11] .debug_line       PROGBITS        00000000 034640 00cf33 00      0   0  1
  [12] .debug_info       PROGBITS        00000000 041573 01fedb 00      0   0  1
  [13] .debug_abbrev     PROGBITS        00000000 06144e 007bc5 00      0   0  1
  [14] .debug_aranges    PROGBITS        00000000 069018 001a90 00      0   0  8
  [15] .debug_pubnames   PROGBITS        00000000 06aaa8 003323 00      0   0  1
  [16] .debug_str        PROGBITS        00000000 06ddcb 007688 01  MS  0   0  1
  [17] .comment          PROGBITS        00000000 075453 0005a0 00      0   0  1
  [18] .debug_frame      PROGBITS        00000000 0759f4 003cf4 00      0   0  4
  [19] .debug_ranges     PROGBITS        00000000 0796e8 0017a8 00      0   0  1
  [20] .shstrtab         STRTAB          00000000 07ae90 0000df 00      0   0  1
  [21] .symtab           SYMTAB          00000000 07b308 005e60 10     22 922  4
  [22] .strtab           STRTAB          00000000 081168 003e87 00      0   0  1
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)

Program Headers:
  Type           Offset   VirtAddr   PhysAddr   FileSiz MemSiz  Flg Align
  LOAD           0x010000 0x00080000 0x00080000 0x24640 0x42268 RWE 0x10000

 Section to Segment mapping:
  Segment Sections...
   00     .vectors .text .rodata .data .sbss .bss 

All of the program and section headers are in the first 0x10000 bytes of the
file (actually much less than that).  The real data, which is all that RedBoot
needs to load into RAM starts at offset 0x10000 in the file.

> 
> If my analysis is wrong, can you explain what's wrong?
> 
> Do linker scripts have an influence on this? (I mean: other then 
> obviously the number and size of segments)
> 
> Bert
-- 
------------------------------------------------------------
Gary Thomas                 |  Consulting for the
MLB Associates              |    Embedded world
------------------------------------------------------------


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]