On 16.02.2008 19:22, ron minnich wrote:
On Feb 16, 2008 10:08 AM, Carl-Daniel Hailfinger c-d.hailfinger.devel.2006@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:
- 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.
- 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.
- 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 formats.
- Make the LAR headers ELF headers
You're not serious, right?
- Just make LAR itself be an ELF file. I mean, they're very similar anyway.
Nooooooooooooooooooooooooooooooooooooo!
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. - 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 solution.
Did I miss anything essential?
Regards, Carl-Daniel