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

Date: Mon, 7 Jun 1999 16:25:28 +0300 (IDT)
From: Eli Zaretskii <eliz AT is DOT elta DOT co DOT il>
X-Sender: eliz AT is
To: muller AT cerbere DOT u-strasbg DOT fr
cc: djgpp-workers AT delorie DOT com, Charles Sandmann <sandmann AT clio DOT rice DOT edu>
Subject: Re: GDB 4.18 alpha: passing signals and printing registers
In-Reply-To: <3.0.6.32.19990607135047.0081aaa0@ics.u-strasbg.fr>
Message-ID: <Pine.SUN.3.91.990607161720.15539A-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, 7 Jun 1999 muller AT cerbere DOT u-strasbg DOT fr wrote:

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

Is it possible to set the DS limit to something that is slightly less 
than 4KB?  If so, we could set it to 4KB minus the fake exception number, 
and then the debugger could know what signal was that by looking at the 
selector limit.

Another possibility is to make the `forced' variable global.  Then the 
debugger could peek and poke it by reading/writing child's memory.  Of 
course, this would only work when debugging unstripped programs, but I 
think it is good enough for starters.  What do you think?

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

The problem is that the hardware interrupt, like Ctrl-C press,  and the 
exception it causes due to 4KB-limit of DS may be far apart in time, if 
the child doesn't touch any PM memory for some time.  If we trace the 
interrupts themselves, we might have hard time to tell what signal to 
generate.

- Raw text -


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