[coreboot] LAR TODO

[Carl-Daniel Hailfinger]

On 20.02.2008 20:17, Patrick Georgi wrote:
> Am Dienstag, den 19.02.2008, 16:48 +0100 schrieb Patrick Georgi:
>   
>> How about doing segments per file (like right now), and simply
>> prepending their data "section" with the load address (as they already
>> get special treatment anyway).
>>     
> Follow up to this issue: the first bytes would also be compressed
> (otherwise we have a special case again).
>
> Currently the decoding routines only decode a whole file, but at least
> lzma is capable of stopping after a given number of output bytes. The
> only remaining issue is that the actual starting position for the
> decode is then 4 bytes below the intended loading position.
>   

Sorry, that's just horrible(TM). I'd expect that as a emergency band-aid 
hack if the header format was crap, but the header format makes such 
runtime hacks unnecessary.


> Just decoding the first 4 bytes into some scratch space probably won't
> work (easily) because the lz-family uses decompressed data as
> dictionary space..
>
> This could be solved by ordering the segments by the lar tool to be
> highest-start-address-first, but this detail would have to be
> documented in a way that no-one will ever stumble over "weird 4 byte
> memory corruption" without quickly figuring out what's going on.
>   

This guarantees we will never be unemployed because people will hire us 
to understand random crashes in the code. Or they will move to another 
codebase. Being too clever is bad. Having hidden side effects is so 
badbadbad that I lack the words to describe it.

Please remember the problem we're trying to solve: Preserving entry 
point and load address over an unpack/repack cycle. That is a pure LAR 
userspace archiver problem and modifying any firmware code is not a path 
to a viable solution.

Regards,
Carl-Daniel

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