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.
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.
--
Sincerely,
Stephen R. van den Berg.
Hackers view advertising as damage, and route around it.
|