Re: [RFC] control-c handling on Windows...

[Joel Brobecker <brobecker at adacore dot com>]

Hi Chris,

> Thanks for the analysis.  I've talked to Corinna about this since she
> was responsible for the original patch in question.  I think her patch
> still makes sense so I guess your change is required although I can't
> shake the feeling that there is some CreateProcess setting that we're
> missing to deal with this behavior.

I had a second look at the issue that Corinna was facing. I am not
entirely sure that I'm seeing the exact same problem, but the symptoms
are the same (gdbtui's process goes into background).

As far as I can tell, here is the sequence of events that lead to
the problem:

  1. win32_create_inferior creates the process, and then calls
     do_initial_win32_stuff.
  2. do_initial_win32_stuff then gives the terminal to the inferior,
     and then does a wait_for_inferior () until we get the expected
     SIGTRAP.
  3. wait_for_inferior leads us to calling win32_wait which calls
     which in turn calls get_win32_debug_event.
  4. As expected, we get our CREATE_PROCESS_DEBUG_EVENT. As a result,
     we add this new pid to the list of threads calling
     win32_add_thread.
  5. win32_add_thread calls add_thread as well, which calls
     add_thread_with_info. This is where things get interesting:

          if (print_thread_events)
            printf_unfiltered (_("[New %s]\n"), target_pid_to_str (ptid));

When I remove this printf_unfiltered, the startup phase completes fine.
I was going to propose that we therefore remove the target_terminal_ours
out of win32_wait and bracket the call to add_thread with
target_terminal_ours/target_terminal_inferior. Things seemed to work
relatively fine, except that I occasionally got the wrong behavior
when pressing C-c. Also, the new suggestion would not take care of
the multiple DEBUG traces that we can get GDB to print.

As far as I can tell, it almost looks like the SIGINT is buffered
until we switch the terminal to the debugger.  Using printfs,
the sequence I see is: we see the new thread, we switch the terminal
to ours to print the new thread event, we receive the SIGINT...
I just don't understand.

> But, if your patch fixes the problem I'm ok with checking it in.

I think that this is probably the easiest to solve all problems.
Here is the same patch, but with a comment explaining why we temporarily
ignore SIGINT...

2008-05-10  Joel Brobecker  <brobecker@adacore.com>

        * win32-nat.c (win32_wait): Ignore SIGINT while waiting for
        a debug event.

I thought you might have some comments/suggestions on the comment,
so I'll wait for your OK before checking it in.

Thanks,
-- 
Joel

Attachment: win32-nat.c.diff
Description: Text document