[coreboot] LAR TODO
rminnich at gmail.com
Sat Feb 16 23:18:53 CET 2008
On Feb 16, 2008 1:12 PM, Carl-Daniel Hailfinger
<c-d.hailfinger.devel.2006 at gmx.net> wrote:
> But the ELF support outside the LAR utility should be protected by ifdef
> to make it easy to compile it out.
yes. I'd like to be able 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.
me too. But I can tell you two: section type and architecture.
> > 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?
I'm mainly trying to point out the extrema.
> > 5. Just make LAR itself be an ELF file. I mean, they're very similar anyway.
Good. I am glad to see that reaction :-)
> The patch has never been committed. No backing out needed.
> Repeat: The patch has never been committed.
I keep forgetting that.
> 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.
> - Sections.
> .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?
I'll leave it to the list :-)
More information about the coreboot