From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 17343 invoked by alias); 9 May 2008 07:53:28 -0000 Received: (qmail 17333 invoked by uid 22791); 9 May 2008 07:53:28 -0000 X-Spam-Check-By: sourceware.org Received: from mtaout7.012.net.il (HELO mtaout7.012.net.il) (84.95.2.19) by sourceware.org (qpsmtpd/0.31) with ESMTP; Fri, 09 May 2008 07:53:08 +0000 Received: from HOME-C4E4A596F7 ([83.130.255.47]) by i-mtaout7.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0K0L000V3BR2HJ20@i-mtaout7.012.net.il> for gdb@sources.redhat.com; Fri, 09 May 2008 10:35:26 +0300 (IDT) Date: Fri, 09 May 2008 07:53:00 -0000 From: Eli Zaretskii Subject: Switching to thread X-012-Sender: halo1@inter.net.il To: gdb@sources.redhat.com Reply-to: Eli Zaretskii Message-id: 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/msg00072.txt.bz2 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?