Date: Sun, 19 May 2002 13:21:38 +0300 (IDT)
From: Eli Zaretskii <eliz AT is DOT elta DOT co DOT il>
X-Sender: eliz AT is
To: Laurynas Biveinis <lauras AT softhome DOT net>
cc: Charles Sandmann <sandmann AT clio DOT rice DOT edu>, djgpp-workers AT delorie DOT com
Subject: Re: Re[2]: emacs under w2k
In-Reply-To: <140241488321.20020519115700@softhome.net>
Message-ID: <Pine.SUN.3.91.1020519130432.17558B-100000@is>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
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


On Sun, 19 May 2002, Laurynas Biveinis wrote:

> Here it is, at least the type of failure has changed. Now it is
> SIGTRAP, and it does not take down gdb. Is the lcall jump address
> calculated incorrectly or what?

I think this is a false alarm: you are stepping through code that invokes 
Int 31h and calls our 16-bit helper code, and that is tricky.  `stepi' 
tries to step _into_ the called functions, which sometimes will not 
work in these cases, or cause SIGTRAPs like you saw.

(SIGTRAP while stepping generally means a GDB bug: it doesn't recognize 
that the exception was caused by a breakpoint or single-step bit in 
EFLAGS it itself have set up.  Single-stepping through assembly code 
which invokes system calls via Int 31h is one twilight zone where these 
problems happen...)

So how about setting a breakpoint in brk_common, then letting it run 
until it hits that breakpoint, and _then_ step through brk_common?

Specifically, once you have Emacs stopped where gmalloc calls __sbrk, 
type these commands:

	(gdb) b brk_common
	(gdb) display/i $pc
	(gdb) c

Then, once the breakpoint inside brk_common breaks, step through it with 
`nexti' (not `stepi'!).  To avoid tripping over these spurious SIGTRAPs,
whenever you see a call to Int 31h or an lcall through indirect PC, put a 
breakpoint after the call and type `c' instead of single-stepping 
through the call.  Then resume stepping with `nexti'.  (Stepping through 
Int 31h calls should generally work, but I find it not very reliable, so 
it's best to avoid that.)

> 0x000013fe in brk_common ()
> 1: x/i $eip  0x13fe <brk_common+78>:    mov    $0x900,%ax
> (gdb)
> 0x00001402 in brk_common ()
> 1: x/i $eip  0x1402 <brk_common+82>:    int    $0x31
> (gdb)
> 0x00001404 in brk_common ()
> 1: x/i $eip  0x1404 <brk_common+84>:    push   %eax
> (gdb)
> 0x00001405 in brk_common ()
> 1: x/i $eip  0x1405 <brk_common+85>:    lcall  *0x10f080
> (gdb)
> Exiting due to signal SIGTRAP

The line that crashes is this one:

   LCALL(sbrk16_api_ofs)

So it's calling our 16-bit helper.  That might explain why stepping into 
that call doesn't work.  Thus, this is one of the cases where I'd suggest 
to set a breakpoint on the line following the lcall:

   setc    %dl

and type `continue'.