Mail Archives: djgpp-workers/2001/09/21/02:12:34
On Thu, 20 Sep 2001, Charles Sandmann wrote:
> > > (Our debuggers
> > > suppress reading the first 4K page, which must be re-enabled to debug
> > > what's happening with UPX images).
> >
> > Could you please elaborate on this? I don't think I'm familiar with
> > this issue.
>
> The way UPX works is it is a small decompressor - less than 4Kb. It is
> built to load itself in the 0-0x1000 address spaces, with the image data
> stored after it. So, if you load a UPX image in the debugger, you
> will see an EIP of less than 0x1000 (and typically a meaningless
> instruction stream if you disassemble).
>
> dbgcom (in the read_child routine) has some "extra" code to prevent
> hitting the child's null page protection - it won't attempt to touch
> addresses less than 4096 bytes. It silently fails and doesn't set
> the memory. Try to run edebug32 on a UPXed image and observe :-)
>
> If you want to see what's happening in the UPX decompressor before
> jumping to the initial starting address you must turn off the extra
> read_child protection code. Usually we assume UPX is bug free and
> just decompress the image if we want to run it under a debugger.
> But if the EIP crash point is in UPX it would be interesting to debug
> the decompressor itself (thus the need to turn off the protection).
>
One can simply test whether UPX is guilty in these problems under WinNT:
Binaries can be unpacked with UPX-1.20 (I used this version), for example:
upx -d cc1.exe
If that fixes the problem, we should suspect UPX and I should avoid using
UPX in nearest future
However I checked that binaries of gcc-3.0 (ones from v2gnu/alphas)
was also compressed with the same UPX version and I didn't get
messages about similar instability. Perhaps one should test that
once more
Andris
- Raw text -