Mail Archives: djgpp-workers/1999/06/07/07:49:05
At 11:00 06/06/99 +0300, you wrote:
>It seems that the current debug support cannot deliver signals to the
>debuggee. For example, I cannot get anything useful out of GDB
>commands like "signal SIGINT" or "handle SIGINT pass". This is
>unfortunate, since some interactive programs use SIGINT or SIGQUIT to
>interrupt operations that are either lengthy or went awry, and longjmp
>to the top-level command loop; debugging such programs is very hard
>without being able to deliver signals.
The problem with SIGINT and SIGQUIT is that these are fake exception.
They appear in real mode, we then change the ds limit to $0xfff
so that the next use of ds (or ss) selector gives a exception 13.
The dbgcom.c code traces the changes to the selector limits
and if it knows that currently the ds selector has a limit of $0xfff
then it knows that it is a fake exception !
But the problem is that it cannot know which fake exception was generated !
That was the sense of the last proposal for a change in excptn.S
I made, though I agree with you thzt this will not solve the problems
for already compiled programs !
One possibility outside this proposal would be to let
the debuggee handle the fake exception by restoring the ds limit to $0xfff
but I have no idea how we could get the forced value we need
to know which exception was triggered !
The last solution is to intercept the real mode interrupts
and to write special real mode interrupts that are only active when the
child is running,
and that will invalidate both GDB and the debuggee selectors so we know
which real mode interruption was generated and thus translated it into
the appropriate SIG number !
- Raw text -