From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 3757 invoked by alias); 9 May 2008 16:43:11 -0000 Received: (qmail 3748 invoked by uid 22791); 9 May 2008 16:43:10 -0000 X-Spam-Check-By: sourceware.org Received: from rock.gnat.com (HELO rock.gnat.com) (205.232.38.15) by sourceware.org (qpsmtpd/0.31) with ESMTP; Fri, 09 May 2008 16:42:53 +0000 Received: from localhost (localhost.localdomain [127.0.0.1]) by filtered-rock.gnat.com (Postfix) with ESMTP id 52B7F2A96AE; Fri, 9 May 2008 12:42:51 -0400 (EDT) Received: from rock.gnat.com ([127.0.0.1]) by localhost (rock.gnat.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 3O9z7C07jOpZ; Fri, 9 May 2008 12:42:51 -0400 (EDT) Received: from joel.gnat.com (localhost.localdomain [127.0.0.1]) by rock.gnat.com (Postfix) with ESMTP id 03A6F2A96C1; Fri, 9 May 2008 12:42:50 -0400 (EDT) Received: by joel.gnat.com (Postfix, from userid 1000) id 8D905E7ACD; Fri, 9 May 2008 09:42:48 -0700 (PDT) Date: Fri, 09 May 2008 16:43:00 -0000 From: Joel Brobecker To: Eli Zaretskii Cc: gdb@sources.redhat.com Subject: Re: Switching to thread Message-ID: <20080509164248.GR7421@adacore.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.2i 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/msg00076.txt.bz2 > 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