Re: gdb-6.6 mingw port hangs after Ctrl-C

[Christopher Faylor <cgf-use-the-mailinglist-please@sourceware.org>]

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