Re: Switching to thread

[Joel Brobecker <brobecker@adacore.com>]

> The announcements can be controlled by "set print thread-events", but
> what about the switching to the new thread? can I tell GDB not to
> switch to it, but rather stay with the one it was before, or is this
> somehow hard-wired in the code?

I don't think the debugger is actually switching to the new thread
when reacting to a new-thread event (while doing the target_wait).
When the new thread is created, win32_wait indeed returns the pid
of the new thread, but handle_for_inferior_event immediately resumes
the execution without changing inferior_ptid.

> The specific use case where this is important is interrupting an
> inferior that appears to be hung with Ctrl-C: on Windows, this creates
> a new thread which runs the SIGINT handler, but I don't normally want
> to see this thread; instead, I want to know where is the mainline code
> looping.  Of course, "thread 1" is all I need to do, but it's easy to
> forget, especially if you did a lot of debugging on something other
> than Windows before that ;-)

What happens in this case is that, after the new thread was created
(and GDB resumed it without having switched to that thread), this new
thread receives the SIGINT. Check case EXCEPTION_DEBUG_EVENT inside
get_win32_debug_event(): 

      switch (handle_exception (ourstatus))
        {
        [...]
        case 1:
          retval = current_event.dwThreadId;

The retval is the thread_id that we then use in win32_nat
to build the ptid returned to the infrun module.

We might be able to avoid that thread switch during Control-C
event by tweaking current_event.dwThreadId to use the thread
id of the inferior_ptid - so as a result, GDB will think that
the SIGINT was received by the current thread rather than
the handler thread.  But I'm really not sure about that. Although
practical, it feels like we're lying a little to the user, since
the SIGINT was received by the handler thread, right?

-- 
Joel