From:	muller AT cerbere DOT u-strasbg DOT fr
Message-Id:	<3.0.6.32.19990607164232.00824a70@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 16:42:32 +0200
To:	djgpp-workers AT delorie DOT com
Subject:	Re: GDB 4.18 alpha: passing signals and printing registers
In-Reply-To:	<Pine.SUN.3.91.990607161720.15539A-100000@is>
References:	<3 DOT 0 DOT 6 DOT 32 DOT 19990607135047 DOT 0081aaa0 AT ics DOT u-strasbg DOT fr>
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

At 16:25 07/06/99 +0300, you wrote:
>
>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.
 That would also be possible, but it has the same drawback that
it does not work with old compiled code !

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

 This would also allow to ignore the signal correctly !

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

"handle SIGINT stop pass" would on the contrary
create a SIGINT in the debuggee !

  The only fear I have is that :
 - this will required that we copy about all of exceptn.S code into
dbgcom.c code

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

- Raw text -