On Feb 16, 2008 1:12 PM, Carl-Daniel Hailfinger <[EMAIL PROTECTED]> 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 > formats. probably not. > > > 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. > > > > 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 -- coreboot mailing list [email protected] http://www.coreboot.org/mailman/listinfo/coreboot
