[coreboot] Time for a new project

[ron minnich]

On Sat, Apr 12, 2008 at 6:36 AM, Philip Schulz
<philip.s.schulz at googlemail.com> wrote:
> Hi,
>
>   For the unexperienced like me: Why would anybody need either LAR or
>  SELF? I kind of understand the reasoning behind LAR, but why would
>  SELF be neccessary? Can't you just extract a regular ELF file from a
>  LAR archive and then load it?


ELF fails on several fronts. Elf is for execution and linking. It
mixes two kinds of things in one file. You would think, with all the
junk they put in there, that it would get it right. As we can see,
they didn't even get the 64/32 thing right, which is amazing.

But let's suppose you have the ELF for /bin/cat:
Section Headers:
  [Nr] Name              Type            Addr     Off    Size   ES Flg Lk Inf Al
  [ 0]                   NULL            00000000 000000 000000 00      0   0  0
  [ 1] .interp           PROGBITS        08048114 000114 000013 00   A  0   0  1
  [ 2] .note.ABI-tag     NOTE            08048128 000128 000020 00   A  0   0  4
  [ 3] .hash             HASH            08048148 000148 00014c 04   A  5   0  4
  [ 4] .gnu.hash         GNU_HASH        08048294 000294 000030 04   A  5   0  4
  [ 5] .dynsym           DYNSYM          080482c4 0002c4 0002c0 10   A  6   1  4
  [ 6] .dynstr           STRTAB          08048584 000584 0001b3 00   A  0   0  1
  [ 7] .gnu.version      VERSYM          08048738 000738 000058 02   A  5   0  2
  [ 8] .gnu.version_r    VERNEED         08048790 000790 000060 00   A  6   1  4
  [ 9] .rel.dyn          REL             080487f0 0007f0 000020 08   A  5   0  4
  [10] .rel.plt          REL             08048810 000810 000138 08   A  5  12  4
  [11] .init             PROGBITS        08048948 000948 000030 00  AX  0   0  4
  [12] .plt              PROGBITS        08048978 000978 000280 04  AX  0   0  4
  [13] .text             PROGBITS        08048c00 000c00 0024c8 00  AX  0   0 16
  [14] .fini             PROGBITS        0804b0c8 0030c8 00001c 00  AX  0   0  4
  [15] .rodata           PROGBITS        0804b100 003100 000baf 00   A  0   0 32
  [16] .eh_frame         PROGBITS        0804bcb0 003cb0 000004 00   A  0   0  4
  [17] .ctors            PROGBITS        0804c000 004000 000008 00  WA  0   0  4
  [18] .dtors            PROGBITS        0804c008 004008 000008 00  WA  0   0  4
  [19] .jcr              PROGBITS        0804c010 004010 000004 00  WA  0   0  4
  [20] .dynamic          DYNAMIC         0804c014 004014 0000d0 08  WA  6   0  4
  [21] .got              PROGBITS        0804c0e4 0040e4 000008 04  WA  0   0  4
  [22] .got.plt          PROGBITS        0804c0ec 0040ec 0000a8 04  WA  0   0  4
  [23] .data             PROGBITS        0804c194 004194 00003c 00  WA  0   0  4
  [24] .bss              NOBITS          0804c1e0 0041d0 000168 00  WA  0   0 32
  [25] .gnu_debuglink    PROGBITS        00000000 0041d0 000008 00      0   0  1
  [26] .shstrtab         STRTAB          00000000 0041d8 0000d1 00      0   0  1

whew! what's all that? It's stuff you use for linking. Why is it
there? because cat gets linked to things at runtime.

Note the .bss ... it's in the L part, the "Link" part.

What else is in there?
Program Headers:
  Type           Offset   VirtAddr   PhysAddr   FileSiz MemSiz  Flg Align
  PHDR           0x000034 0x08048034 0x08048034 0x000e0 0x000e0 R E 0x4
  INTERP         0x000114 0x08048114 0x08048114 0x00013 0x00013 R   0x1
      [Requesting program interpreter: /lib/ld-linux.so.2]
  LOAD           0x000000 0x08048000 0x08048000 0x03cb4 0x03cb4 R E 0x1000
  LOAD           0x004000 0x0804c000 0x0804c000 0x001d0 0x00348 RW  0x1000
  DYNAMIC        0x004014 0x0804c014 0x0804c014 0x000d0 0x000d0 RW  0x4
  NOTE           0x000128 0x08048128 0x08048128 0x00020 0x00020 R   0x4
  GNU_STACK      0x000000 0x00000000 0x00000000 0x00000 0x00000 RW  0x4

program headers, which is stuff for when you run. These are images to
load to memory.

Note that bss is not in the program headers ... and knowing about bss
is pretty important at load time on an embedded system. Note that
a.out actually got this right, but who needs a working 40-year-old
design when we've got a broken 20-year-old design :-)

Other issues. We had compressed ELF. So I got to watch coreboot
uncompress the elf *somewhere* and then deal with having to memcpy the
uncompressed elf sections *somewhere else*. That's gross. I got a nice
speedup when I got rid of ELF in v3 -- it was actually noticeable.

Finally ... people (me included) keep messing up ELF parsers. The GNU
BFD tools don't quite get it right, in fact objdump used to coredump
on some valid ELF files, which is why we have readelf. I know one
large company that totally blew it and implemented a simulator which
used section headers and not program headers. We had to modify the
plan 9 linker to generate bogus ELF files for that system. The
linuxbios ELF parser was always broken, and we didn't know it: it
always assumed the program header section of elf came first, which it
does *almost* all the time. But not always. It can come at the back.
You have to read the entire ELF file to find out what's in the file.
That's really bad if you have a streaming source of data, e.g. a
serial line.

There is just so much wrong with ELF. I was happy to get it out of the
ROM BIOS :-)

Good question, thanks for asking, we now return you the Great Debate :-)

ron