[coreboot] Time for a new project
ron minnich
rminnich at gmail.com
Sun Apr 13 00:01:01 CEST 2008
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
More information about the coreboot
mailing list