Mail Archives: djgpp-workers/1999/05/26/05:07:29
On 25 May 99, at 10:51, Eli Zaretskii wrote:
>
> 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?
In some conditions debugger does not get signal code from
debugee. That was rather serious problem but at least partial
solution was found. Drawback is that SIGQUIT is misinterpretted
as SIGINT and perhaps also the same with SIGALRM (however I
haven't tested it).
Currently I see possible solution for keyboard generated signal
(SIGINT and SIGQUIT) and also perhaps for SIGFPE (currently we
simply forbid hooking SIGFPE exception handler in dbgcom.c).
This should require rather big additional code in dbgcom.c and I'm
not sure we'll need to put that in 2.03. More likely that is topic for
2.04.
Other possibility is putting signal number in some unused register
when setting DS selector limit to one page in exceptn.S. Then
dbgcom.c would be able to get it (checking when debugee is
setting limit of application DS selector to 0xFFF) . Problem: if we
put it in 2.03 then it will not work with any earlier versions.
This is reason why I don't like similar changes in exceptn.S.
SIGALRM is beast slightly worse as it can be handled in debugee
only so only second way can succeed.
Andris
- Raw text -