www.delorie.com/archives/browse.cgi   search  
Mail Archives: djgpp-workers/1999/06/07/09:11:11

From: pavenis AT lanet DOT lv
Message-ID: <B0000089576@stargate.astr.lu.lv>
To: djgpp-workers AT delorie DOT com
Date: Mon, 7 Jun 1999 16:11:02 +0300
MIME-Version: 1.0
Subject: Re: GDB 4.18 alpha: passing signals and printing registers
In-reply-to: <3.0.6.32.19990607135047.0081aaa0@ics.u-strasbg.fr>
References: <Pine DOT SUN DOT 3 DOT 91 DOT 990606105845 DOT 16109D-100000 AT is>
X-mailer: Pegasus Mail for Win32 (v3.11)
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 7 Jun 99, at 13:50, muller AT cerbere DOT u-strasbg DOT fr wrote:

> 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 !
> 

I would suggest following modification of exceptn.S. It will provide
exception code in lower byte of %esi. Other bytes in %esi will 
contain some signature (we should choose something which is not 
very likely to expect randomly).

Similary in dbgcom.c we should check for this signature and fall 
back to current behaviour when debugging binaries compiled using
earlier versions of libc.

Andris

*** exceptn.S~2	Sat Feb 20 16:41:46 1999
--- exceptn.S	Tue Jun  1 18:08:40 1999
***************
*** 436,452 ****
--- 436,457 ----
  	pushl	%ebx
  	pushl	%ecx
  	pushl	%edx
+         pushl   %esi
  	pushl	%ds
  	movw	%cs:___djgpp_our_DS, %ds
  	movl	___djgpp_app_DS, %ebx		/* avoid size prefix */
  	lsl	%ebx, %ecx
  	movl	%ecx, ds_limit			/* Save current limit */
  	movb	%al, forced			/* Indicate a fake exception */
+         movl    $98765400, %ecx                 /* Some signature */
+         movb    %al, %cl
+         movl    %ecx, %esi
  	xorl	%ecx, %ecx
  	movw	$0xfff, %dx			/* 4K limit is null page ! */
  	movw	$0x0008, %ax
  	int	$0x31				/* Set segment limit */
  5:	popl	%ds
+         popl    %esi
  	popl	%edx
  	popl	%ecx
  	popl	%ebx

- Raw text -


  webmaster     delorie software   privacy  
  Copyright © 2019   by DJ Delorie     Updated Jul 2019