From: sandmann AT clio DOT rice DOT edu (Charles Sandmann)
Message-Id: <10109211311.AA18258@clio.rice.edu>
Subject: Re: UPX'ed image and debugger note [was Re: gcc-3.01 ...]
To: eliz AT is DOT elta DOT co DOT il
Date: Fri, 21 Sep 2001 08:11:32 -0500 (CDT)
Cc: djgpp-workers AT delorie DOT com
In-Reply-To: <7263-Fri21Sep2001102144+0300-eliz@is.elta.co.il> from "Eli Zaretskii" at Sep 21, 2001 10:21:44 AM
X-Mailer: ELM [version 2.5 PL2]
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Reply-To: djgpp-workers AT delorie DOT com
Errors-To: nobody AT delorie DOT com
X-Mailing-List: djgpp-workers AT delorie DOT com
X-Unsubscribes-To: listserv AT delorie DOT com
Precedence: bulk

> > 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).
> 
> Is UPX built with DJGPP?  If not, what use is it to try to debug it
> with DJGPP debuggers?

I mean images compressed with UPX.  If (*AND THAT IS A HUGE IF WITHOUT 
MORE INFO*) the crash is in the decompressor we would need the debugger
to be a bit smarter.

> ... doesn't its memory layout violate some of
> the assumptions in dbgcom.c and v2load.c?

Maybe a few assumptions (such as null page never used) but nothing that
can't be fixed.

> > 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.
> 
> Right, and for a good reason.  We could of course avoid doing that if
> UPX is involved, but we need a way to detect this situation.  Can you
> suggest how to detect that?

How about a flag that says if the current CS:IP is < 4096 then allow
reads?

> > 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).
> 
> A user of a debugger might also want to turn off null page protection
> if they want to put a watchpoint on it.  This might come handy for
> debugging on Windows, where we don't get a SIGSEGV in the debuggee
> when it dereferences a NULL pointer.

True.  But the debuggers internally treat 0 as the flag to disable
a watchpoint, so this would need to be changed.