On Thu, 20 Aug 2009, Stephen R. van den Berg wrote:
> I briefly tried to look into using gzip/gunzip on .o files. However, in order
> to understand the intricacies and tradeoffs between memory usage and speed,
> I'm not quite sure I understand what is going on at the lowest levels when
> a .o file is loaded.
>
> Anyone care to elaborate in what way the following overview is misleading
> with regard to how things are done currently?
>
> Sequence of events when loading a .o file:
> a. The entire content of the .o file gets copied into a string in memory.
> b. The .o string gets unpacked into some structure which the interpreter
> can use.
> c. The original string containing the .o file content is dropped from memory.
>
> Correct? Or are step b and c no-ops because (part of) the string is
> interpreted (as is) whenever the interpreter needs it.
That's more or less correct.
> If abc is correct, can anyone point me to the spot where all .o files
> eventually run through a/the decoder? It would probably be trivial to
> intercept at that point, check for a gzip magic number at the start and
> decompress before handing it to the actual decoder.
All *.o files except for the master program itself are decoded via the
master object. The docoding of dumped files is done by the call of
decode_value() in low_findprog().
> Sincerely,
> Stephen R. van den Berg.
--
Henrik Grubbström <grubba[at]roxen.com>
Roxen Internet Software AB
|