Switching to thread

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?

> 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

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?

> Date: Fri, 9 May 2008 09:42:48 -0700
> From: Joel Brobecker <brobeckeradacore.com>
> Cc: gdbsources.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.