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