Date:	Tue, 25 May 1999 10:51:06 +0300 (IDT)
From:	Eli Zaretskii <eliz AT is DOT elta DOT co DOT il>
X-Sender:	eliz AT is
To:	djgpp-workers AT delorie DOT com
cc:	Robert Hoehne <robert DOT hoehne AT gmx DOT net>,
	Pierre Muller <muller AT cerbere DOT u-strasbg DOT fr>
Subject:	Re: gdb 4.18 for DJGPP (alpha)
In-Reply-To:	<Pine.SUN.3.91.990524161540.7396E-100000@is>
Message-ID:	<Pine.SUN.3.91.990525104631.24405I-100000@is>
MIME-Version:	1.0
Reply-To:	djgpp-workers AT delorie DOT com
X-Mailing-List:	djgpp-workers AT delorie DOT com
X-Unsubscribes-To:	listserv AT delorie DOT com

On Mon, 24 May 1999, Eli Zaretskii wrote:

> > Of course. GDB gets TARGET_WAITKIND_SIGNALLED that is 
> > command to kill debugee. We should have 
> > TARGET_WAITKIND_STOPPED to avoid that.
> 
> But the v2.03 branch already returns TARGET_WAITKIND_STOPPED.  And that 
> causes GDB to report SIGTRAP on every breakpoint instead of recognizing 
> the breakpoint as such.
 
Okay, it turned out this was due to a stupid typo, entirely my fault.
Sorry I wasted everybody's time.

The binary built with the v2.03 branch of go32-nat.c enabled does
allow to resume the debuggee after a signal.  But I have another
problem: SIGQUIT (generated by pressing Ctrl-\) is reported as SIGINT,
even though I fixed go32-nat.c to know about fake exception 0x7a
generated by SIGQUIT.

It appears that this is somehow connected to this fragment from
dbgcom.c (in `dbgsig' function):

     /* I still have no idea how to get the exception number back */
     /* just keep the fake exception value */
     signum=0x1B;
     __djgpp_exception_state->__signum=signum;

Can someone please explain what's the story behind this snippet?  Why
is it a problem to get the original exception at that point, and what
are the implications of this?  Does it mean, for example, that SIGALRM
will also be reported as SIGINT?

- Raw text -