* win32-nat.c (win32_wait): Block the control-c event while
waiting for a debug event.
This commit is contained in:
parent
9f1d377b33
commit
c57918b25b
|
@ -1,3 +1,8 @@
|
||||||
|
2008-05-20 Joel Brobecker <brobecker@adacore.com>
|
||||||
|
|
||||||
|
* win32-nat.c (win32_wait): Block the control-c event while
|
||||||
|
waiting for a debug event.
|
||||||
|
|
||||||
2008-05-19 Pedro Alves <pedro@codesourcery.com>
|
2008-05-19 Pedro Alves <pedro@codesourcery.com>
|
||||||
|
|
||||||
* symtab.h (lookup_symbol_in_language): Update comment.
|
* symtab.h (lookup_symbol_in_language): Update comment.
|
||||||
|
|
|
@ -1458,7 +1458,25 @@ win32_wait (ptid_t ptid, struct target_waitstatus *ourstatus)
|
||||||
|
|
||||||
while (1)
|
while (1)
|
||||||
{
|
{
|
||||||
int retval = get_win32_debug_event (pid, ourstatus);
|
int retval;
|
||||||
|
|
||||||
|
/* Ignore CTRL+C signals while waiting for a debug event.
|
||||||
|
FIXME: brobecker/2008-05-20: When the user presses CTRL+C while
|
||||||
|
the inferior is running, both the inferior and GDB receive the
|
||||||
|
associated signal. If the inferior receives the signal first
|
||||||
|
and the delay until GDB receives that signal is sufficiently long,
|
||||||
|
GDB can sometimes receive the SIGINT after we have unblocked
|
||||||
|
the CTRL+C handler. This would lead to the debugger to stop
|
||||||
|
prematurely while handling the new-thread event that comes
|
||||||
|
with the handling of the SIGINT inside the inferior, and then
|
||||||
|
stop again immediately when the user tries to resume the execution
|
||||||
|
in the inferior. This is a classic race, and it would be nice
|
||||||
|
to find a better solution to that problem. But in the meantime,
|
||||||
|
the current approach already greatly mitigate this issue. */
|
||||||
|
SetConsoleCtrlHandler (NULL, TRUE);
|
||||||
|
retval = get_win32_debug_event (pid, ourstatus);
|
||||||
|
SetConsoleCtrlHandler (NULL, FALSE);
|
||||||
|
|
||||||
if (retval)
|
if (retval)
|
||||||
return pid_to_ptid (retval);
|
return pid_to_ptid (retval);
|
||||||
else
|
else
|
||||||
|
|
|
@ -1458,7 +1458,25 @@ win32_wait (ptid_t ptid, struct target_waitstatus *ourstatus)
|
||||||
|
|
||||||
while (1)
|
while (1)
|
||||||
{
|
{
|
||||||
int retval = get_win32_debug_event (pid, ourstatus);
|
int retval;
|
||||||
|
|
||||||
|
/* Ignore CTRL+C signals while waiting for a debug event.
|
||||||
|
FIXME: brobecker/2008-05-20: When the user presses CTRL+C while
|
||||||
|
the inferior is running, both the inferior and GDB receive the
|
||||||
|
associated signal. If the inferior receives the signal first
|
||||||
|
and the delay until GDB receives that signal is sufficiently long,
|
||||||
|
GDB can sometimes receive the SIGINT after we have unblocked
|
||||||
|
the CTRL+C handler. This would lead to the debugger to stop
|
||||||
|
prematurely while handling the new-thread event that comes
|
||||||
|
with the handling of the SIGINT inside the inferior, and then
|
||||||
|
stop again immediately when the user tries to resume the execution
|
||||||
|
in the inferior. This is a classic race, and it would be nice
|
||||||
|
to find a better solution to that problem. But in the meantime,
|
||||||
|
the current approach already greatly mitigate this issue. */
|
||||||
|
SetConsoleCtrlHandler (NULL, TRUE);
|
||||||
|
retval = get_win32_debug_event (pid, ourstatus);
|
||||||
|
SetConsoleCtrlHandler (NULL, FALSE);
|
||||||
|
|
||||||
if (retval)
|
if (retval)
|
||||||
return pid_to_ptid (retval);
|
return pid_to_ptid (retval);
|
||||||
else
|
else
|
||||||
|
|
Loading…
Reference in New Issue