www.delorie.com/archives/browse.cgi   search  
Mail Archives: djgpp-workers/1999/06/08/05:56:35

Date: Tue, 8 Jun 1999 11:30:40 +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
Subject: Re: GDB 4.18 alpha: passing signals and printing registers
In-Reply-To: <3.0.6.32.19990607164232.00824a70@ics.u-strasbg.fr>
Message-ID: <Pine.SUN.3.91.990608113007.4197C-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:

> >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?
> 
>   Same remark as above plus that it would also not work and newlyy compiled
> but stripped code !
>   Moreover this would mean adding GDB specifc code into dbgcom.c !

The latter comment is not what I had in mind.  I didn't mean to add
code that reads and writes `forced' to dbgcom.c, I meant adding it to
the DJGPP-specific parts of GDB (go32-nat.c).  RHIDE is also based on
GDB, so it will benefit as well.

> >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.
>  No, because the type of SIG is determined in the real interrupt handler by
> setting the forced value !

Note that the code in the interrupt handler that sets `forced'
examines `forced' first, to see if some signal is already pending.
You would need to duplicate the same logic to make the correct
decision, and any change in exceptn.S which affects that should be
reflected in dbgcom.c to make it work.

>  So "handle SIGINT stop ignore "
> would then get the debuggee to stop when you press Crtl-C
> but "cont " would resume the program unaffected.

This happens today, with the current dbgcom.c already.

>   That code lead to already known problems especially
> when using WinNT OS !

Which problems are these?

- Raw text -


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