i386 gdbserver for windows: break problem

i386 gdbserver for windows: break problem

[Khaled Jmal]

Hi all,

I'm using gdbserver 6.6 and I compiled it for windows with mingw.
It looks like the break is not working. The gdbserver doesn't react to CTRL-C
Is this function implemented

I tried to patch the gdbserver so that it polls the status when the application is running.
With GenerateConsoleCtrlEvent I could stop the application but only if the application
shares the same console as the gdbserver.

Any help?


Thanks,
Khaled




	

	
		
___________________________________________________________________________ 
Découvrez une nouvelle façon d'obtenir des réponses à toutes vos questions ! 
Profitez des connaissances, des opinions et des expériences des internautes sur Yahoo! Questions/Réponses 
http://fr.answers.yahoo.com

Re: i386 gdbserver for windows: break problem

[Lerele]

Khaled Jmal wrote:

>Hi all,
>
>I'm using gdbserver 6.6 and I compiled it for windows with mingw.
>It looks like the break is not working. The gdbserver doesn't react to CTRL-C
>Is this function implemented
>
>I tried to patch the gdbserver so that it polls the status when the application is running.
>With GenerateConsoleCtrlEvent I could stop the application but only if the application
>shares the same console as the gdbserver.
>
>Any help?
>
>
>Thanks,
>Khaled
>
>
>  
>

The gdbserver for Win32 patch I submitted did not include that support.

I did work on that some months ago to let client gdb interrupt the 
remotely debugged process, but never actually submitted the patch. It 
did work somewhat, but the approach wasn't correct because the way I 
handled interrupt support interfered too much with debugged process 
execution, and it was somewhat buggy.
I know it's very annoying not to be able to interrupt remote process, 
but I have not found time to implement that support correctly, sorry. 
It's on my todo. I will do it eventually, if nobody else does first.


Leo.








>
>	
>
>	
>		
>___________________________________________________________________________ 
>Découvrez une nouvelle façon d'obtenir des réponses à toutes vos questions ! 
>Profitez des connaissances, des opinions et des expériences des internautes sur Yahoo! Questions/Réponses 
>http://fr.answers.yahoo.com
>
>  
>

Re: i386 gdbserver for windows: break problem

[Michael Snyder]

On Wed, 2007-02-21 at 19:16 +0100, Lerele wrote:
> Khaled Jmal wrote:
> 
> >Hi all,
> >
> >I'm using gdbserver 6.6 and I compiled it for windows with mingw.
> >It looks like the break is not working. The gdbserver doesn't react to CTRL-C
> >Is this function implemented
> >
> >I tried to patch the gdbserver so that it polls the status when the application is running.
> >With GenerateConsoleCtrlEvent I could stop the application but only if the application
> >shares the same console as the gdbserver.
> >
> >Any help?
> >
> >
> >Thanks,
> >Khaled
> >
> >
> >  
> >
> 
> The gdbserver for Win32 patch I submitted did not include that support.
> 
> I did work on that some months ago to let client gdb interrupt the 
> remotely debugged process, but never actually submitted the patch. It 
> did work somewhat, but the approach wasn't correct because the way I 
> handled interrupt support interfered too much with debugged process 
> execution, and it was somewhat buggy.
> I know it's very annoying not to be able to interrupt remote process, 
> but I have not found time to implement that support correctly, sorry. 
> It's on my todo. I will do it eventually, if nobody else does first.

Control-c has always been problematic for gdb on windows.
Windows doesn't treat control-c at all like other os's do.

Re: i386 gdbserver for windows: break problem

[Eli Zaretskii]

> From: Michael Snyder <Michael.Snyder@palmsource.com>
> Cc: Khaled Jmal <khaledjmal@yahoo.fr>, gdb@sourceware.org
> Date: Wed, 21 Feb 2007 12:02:31 -0800
> 
> Control-c has always been problematic for gdb on windows.
> Windows doesn't treat control-c at all like other os's do.

Actually, Ctrl-C handling on Windows is very similar to Posix.  The
only major problem that I'm aware of is that the Ctrl-C handler runs
in a separate thread, so a single-threaded program suddenly becomes
multi-threaded, and in particular one can have race condition between
the main thread and the signal thread.