This is the mail archive of the gdb-patches@sourceware.org mailing list for the GDB project.
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |
Other format: | [Raw text] |
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
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |