This is the mail archive of the
gdb@sourceware.org
mailing list for the GDB project.
Re: gdb-6.6 mingw port hangs after Ctrl-C
On Mon, Aug 20, 2007 at 03:31:28PM -0400, Daniel Jacobowitz wrote:
>On Mon, Aug 20, 2007 at 10:16:12PM +0300, Eli Zaretskii wrote:
>> The way to fix this is to make the signal handler stop the main thread
>> as the first thing it does. Then you have a Posix-compliant program
>> again. I did something similar for the MinGW port of GNU Make.
>
>Is there any way to force the other thread to longjmp? Otherwise,
>just stopping it isn't enough - you don't have the right stack.
>Erm, maybe it would work anyway... longjmping from one thread to
>another scares me a bit, though.
This is why Cygwin's signal handling code is so complicated.
You can stop another thread with a "SuspendThread()" call and you can
cause the thread to resume in another location with a "ResumeThread()"
by changing the EIP that is passed to it. However, if you do that while
you are in the middle of a low-level Windows function which, say, holds
a mutex, then you are going to eventually run into problems.
It's possible that this isn't a big problem for newer NT-based OSes but
it was a show-stopper for the older versions of Windows and older
versions of Windows NT.
Cygwin works around this by not allowing itself to be suspended within a
Cygwin1.dll function and checking for signal redirection at the end of
any Cygwin function which references Windows. If it notices that a
signal came in then, instead of returning, the function will jump to the
appropriate signal handler. If the signal came in while user-level code
was executing then the main thread is suspended and resumed at a new
location which fixes up the stack so that the equivalent of a longjmp
takes place.
You *might* be able to make gdb do something similar to all of this but
it would obviously be a lot of work.
cgf