Re: Switching to thread

[Michael Snyder <msnyder at specifix dot com>]

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?