rminnich at gmail.com
Wed Apr 16 20:33:55 CEST 2008
On Tue, Apr 15, 2008 at 1:49 PM, Peter Stuge <peter at stuge.se> wrote:
> I guess because we've produced so inconsistent quality ELF files.
In my case it boiled down to several things.
1. Watching the time lost as we decompressed ELF to memory, relocated
things, then did a final memcpy of the segments to their real
destination. That was a big one for me.
2. The times that people experienced a dead stop from coreboot with
the useful message "bad ELF file" or whatever it was. That's a
complete show-stopper IMHO. I realize we can fix this by parsing ELF
at build time. But if we're going to parse ELF at build time, why not
do a little extra work to put it into a loader-friendly format?
3. My weird problems with BSS (and segher is right, it *should* have
worked. It just didn't. BSS is contained in the segments. I think some
part of the "ELF relocation" stuff was losing information about the
segments -- I was not able to see how).
4. The fact that ELF file formats can really inhibit streaming
uncompress -- since in some cases you have program headers at the
*end* of the file, so you have to decompress the whole file to find
out about the file (and, yes, you can fix this with ld, and it
probably will work right on many ld's. But what of the ones it fails
on? I'm tired of debugging the GNU toolchain). And streaming
decompress is really important. We want to be cache friendly, and that
means we should try for one pass over the data. Like it or not, the
original designers of ELF did not seem to anticipate compressed
segments. (yes, we can make our own incompatible flags. How will those
new flags break bfd tools?)
well there are others but let it suffice to say, from my point of view
of almost 9 years on this project, that ELF has been a mixed blessing
from the start.
More information about the coreboot