From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 4549 invoked by alias); 6 Aug 2008 04:41:02 -0000 Received: (qmail 4539 invoked by uid 22791); 6 Aug 2008 04:41:02 -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; Wed, 06 Aug 2008 04:40:27 +0000 Received: from [127.0.0.1] (bluesmobile.specifix.com [216.129.118.140]) by bluesmobile.specifix.com (Postfix) with ESMTP id 27CE23BC58; Tue, 5 Aug 2008 21:40:26 -0700 (PDT) Subject: Re: "thread", "thread apply" and "step" ? From: Michael Snyder To: Rich Wagner Cc: gdb@sourceware.org In-Reply-To: References: Content-Type: text/plain Date: Wed, 06 Aug 2008 04:41:00 -0000 Message-Id: <1217997625.3549.662.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-08/txt/msg00087.txt.bz2 On Tue, 2008-08-05 at 16:11 -0400, Rich Wagner wrote: > I haven't been able to find an "official" GDB spec which answers a > question I have, relating to threads and stepping, so... > > > Say your program has two threads, A and B, and that B most recently hit > a breakpoint. > > It's pretty clear (and my experiments have shown) that if you then > simply execute "step", then the step occurs in B. That is, both threads > resume execution, with both threads suspending again when B reaches the > "end-of-step" boundary. So far, so good... > > However, things become less clear, and non-intuitive, if after B hits a > breakpoint, and I then use: > > thread A > step The short answer is "don't do that". What I *wanted* to say is "you can't do that". The problem is, as you have discovered, you can -- it just doesn't have the effect that you think it should. GDB's "thread" command will specify a thread to which subsequent state queries will apply (eg. "info register"). But GDB does not exercise any control over the operating system's thread scheduling, therefore GDB has no control over which thread will actually run when you say "step" or "continue". You might think it should be the thread that you last selected -- but it won't. It will be the thread that the operating system chooses (generally the one that was most recently running).