On Tue, Apr 15, 2008 at 1:49 PM, Peter Stuge peter@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.
ron