[coreboot] LAR TODO
c-d.hailfinger.devel.2006 at gmx.net
Sat Feb 16 22:12:46 CET 2008
On 16.02.2008 19:22, ron minnich wrote:
> On Feb 16, 2008 10:08 AM, Carl-Daniel Hailfinger
> <c-d.hailfinger.devel.2006 at gmx.net> wrote:
>> It should be reasonably easy tofind out which segment is bss (the one
>> with compalgo "zeroes"), but I'm not so sure about data and code. Do we
>> want any convention (code is always segment0, data is always segment1)?
> and here is Stefan's point. Converting from ELF to LAR is not
> information-preserving. LAR headers have less information.
> The pre-parsing loses information that is in the ELF.
> LAR headers do not save information as to code vs. data, etc.
> Our choices are:
> 1. continue with ELF support (though I do not intend to ever use it :-)
But the ELF support outside the LAR utility should be protected by ifdef
to make it easy to compile it out.
> 2. extend the LAR headers to incorporate more ELF info
I'd like a list of essential pieces of information we lose when parsing
ELF into LAR.
> 3. when we pre-parse ELF files, save the ELF program headers when we
> create the LAR file (except .bss is a section header,
> ELF is really not a very good design in many ways)
I doubt the ELF header alone is good enough to convert between the two
> 4. Make the LAR headers ELF headers
You're not serious, right?
> 5. Just make LAR itself be an ELF file. I mean, they're very similar anyway.
> So, I think we back out Myle's patch, until we resolve this. Stefan
The patch has never been committed. No backing out needed.
Repeat: The patch has never been committed.
> has a point. I still dislike ELF parsing in coreboot. The v2
> code was not actually able to handle all ELF files; it had obscure
> failure modes. The v3 code is even more restrictive.
> Unless we want to greatly grow the ELF code in coreboot, some
> preprocessing is inevitable.
What do we need to reconstruct an ELF file which is equivalent to the
original as far as an ELF loader is concerned?
- Entry point. No problem, is saved in LAR.
- Architecture. Right now, this is constant.
.bss is easy. It's the entry with compression algo "zeroes"
.data is solvable. We have to either make the "data" section
"segment1" by convention or introduce another marker.
.text and .rodata are merged by LAR. Reversing that is neither easy
nor does it make sense. Both are readonly and unless you want .rodata
marked noexec, stuffing them together into .text is a very workable
Did I miss anything essential?
More information about the coreboot