[coreboot] LAR TODO

[Carl-Daniel Hailfinger]

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 
formats.

> 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.
>   

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

-- 
http://www.hailfinger.org/