On Feb 16, 2008 1:12 PM, Carl-Daniel Hailfinger c-d.hailfinger.devel.2006@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.
- 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.
- 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.
probably not.
- Make the LAR headers ELF headers
You're not serious, right?
I'm mainly trying to point out the extrema.
- Just make LAR itself be an ELF file. I mean, they're very similar anyway.
Nooooooooooooooooooooooooooooooooooooo!
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 solution.
Did I miss anything essential?
I'll leave it to the list :-)
ron