From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 16945 invoked by alias); 9 May 2008 19:20:21 -0000 Received: (qmail 16937 invoked by uid 22791); 9 May 2008 19:20:21 -0000 X-Spam-Check-By: sourceware.org Received: from bluesmobile.specifix.com (HELO bluesmobile.specifix.com) (216.129.118.140) by sourceware.org (qpsmtpd/0.31) with ESMTP; Fri, 09 May 2008 19:20:03 +0000 Received: from [127.0.0.1] (bluesmobile.specifix.com [216.129.118.140]) by bluesmobile.specifix.com (Postfix) with ESMTP id 972E93BCCD; Fri, 9 May 2008 12:20:01 -0700 (PDT) Subject: Re: Switching to thread From: Michael Snyder To: Eli Zaretskii Cc: gdb@sources.redhat.com In-Reply-To: References: Content-Type: text/plain Date: Fri, 09 May 2008 19:20:00 -0000 Message-Id: <1210360801.4615.513.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.10.3 (2.10.3-7.fc7) Content-Transfer-Encoding: 7bit X-IsSubscribed: yes Mailing-List: contact gdb-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sourceware.org X-SW-Source: 2008-05/txt/msg00081.txt.bz2 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?