Switching to thread

Switching to thread

[Eli Zaretskii]

Whenever GDB detects a new thread in the inferior, it announces it,
and also switches to that new thread.  At least that's what I see in
GDB 6.8 for i686-pc-mingw32.

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?

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 ;-)

Am I missing something?

Re: Switching to thread

[Joel Brobecker]

> 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

Re: Switching to thread

[Eli Zaretskii]

> Date: Fri, 9 May 2008 09:42:48 -0700
> From: Joel Brobecker <brobecker@adacore.com>
> Cc: gdb@sources.redhat.com
> 
> 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.

Right, I missed this.  Thanks, this makes the situation clear.

Re: Switching to thread

[Michael Snyder]

On Fri, 2008-05-09 at 10:52 +0300, Eli Zaretskii wrote:
> Whenever GDB detects a new thread in the inferior, it announces it,
> and also switches to that new thread.  At least that's what I see in
> GDB 6.8 for i686-pc-mingw32.

In my understanding, it only switches to the thread
if the thread has a stop event (eg. SIGTRAP, SIGINT).

There are other ways in which gdb might detect a new thread
but not switch to it.


> 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 so, normally whenever a thread gets a stop event,
we switch to that thread.  There are some loosely related concepts:

You can arrange for any particular breakpoint to be
thread-specific, so that it will only generate stop
events for some threads (one in particular), not others.

You can "set scheduler-locking", if your target supports 
it, which prevents some threads from running (and therefore
from getting stop events.)

> 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 ;-)
> 
> Am I missing something?

Windows peculiarity -- the SIGINT handler thread is the one
that gets the stop event.  On unix it would (I think) be the
thread that happened to be running at the time.

Maybe there is some windows-specific mechanism for finding
out what thread was running before the SIGINT handler thread
took over?