From: muller AT cerbere DOT u-strasbg DOT fr Message-Id: <3.0.6.32.19990607135047.0081aaa0@ics.u-strasbg.fr> X-Sender: muller AT ics DOT u-strasbg DOT fr X-Mailer: QUALCOMM Windows Eudora Light Version 3.0.6 (32) Date: Mon, 07 Jun 1999 13:50:47 +0200 To: djgpp-workers AT delorie DOT com Subject: Re: GDB 4.18 alpha: passing signals and printing registers In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" 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 Precedence: bulk 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 !