From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 26527 invoked by alias); 18 Aug 2008 16:01:35 -0000 Received: (qmail 26424 invoked by uid 22791); 18 Aug 2008 16:01:31 -0000 X-Spam-Check-By: sourceware.org Received: from mtagate6.de.ibm.com (HELO mtagate6.de.ibm.com) (195.212.29.155) by sourceware.org (qpsmtpd/0.31) with ESMTP; Mon, 18 Aug 2008 16:00:48 +0000 Received: from d12nrmr1607.megacenter.de.ibm.com (d12nrmr1607.megacenter.de.ibm.com [9.149.167.49]) by mtagate6.de.ibm.com (8.13.8/8.13.8) with ESMTP id m7IG0hRQ685546 for ; Mon, 18 Aug 2008 16:00:43 GMT Received: from d12av02.megacenter.de.ibm.com (d12av02.megacenter.de.ibm.com [9.149.165.228]) by d12nrmr1607.megacenter.de.ibm.com (8.13.8/8.13.8/NCO v9.0) with ESMTP id m7IG0glK3903500 for ; Mon, 18 Aug 2008 18:00:42 +0200 Received: from d12av02.megacenter.de.ibm.com (loopback [127.0.0.1]) by d12av02.megacenter.de.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id m7IG0gCi011503 for ; Mon, 18 Aug 2008 18:00:42 +0200 Received: from tuxmaker.boeblingen.de.ibm.com (tuxmaker.boeblingen.de.ibm.com [9.152.85.9]) by d12av02.megacenter.de.ibm.com (8.12.11.20060308/8.12.11) with SMTP id m7IG0gNP011499; Mon, 18 Aug 2008 18:00:42 +0200 Message-Id: <200808181600.m7IG0gNP011499@d12av02.megacenter.de.ibm.com> Received: by tuxmaker.boeblingen.de.ibm.com (sSMTP sendmail emulation); Mon, 18 Aug 2008 18:00:42 +0200 Subject: Re: [rfc] Preferred thread event reporting: Linux native target To: msnyder@vmware.com (Michael Snyder) Date: Mon, 18 Aug 2008 16:01:00 -0000 From: "Ulrich Weigand" Cc: pedro@codesourcery.com (Pedro Alves), gdb-patches@sourceware.org (gdb-patches@sourceware.org) In-Reply-To: <48A5C90E.7080801@vmware.com> from "Michael Snyder" at Aug 15, 2008 11:21:02 AM X-Mailer: ELM [version 2.5 PL2] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org X-SW-Source: 2008-08/txt/msg00488.txt.bz2 Michael Snyder wrote: > Ulrich Weigand wrote: > > Pedro Alves wrote: > > > >>> -- this is actually simply the currently selected thread > >>> (i.e. the current value of inferior_ptid). > >> Disagreed. inferior_ptid will change if an event happens in > >> another thread while you're stepping, but the core decides the event > >> was not a good reason to stop. E.g., thread hopping. > > > > Hmm, but if we "thread hop" inferior_ptid should be prefered > > anyway (to get the internal "thread hop" action over with as > > quickly as possible), and afterwards we're back to the thread > > the user is looking at, right? > > After that, I think, we're back to whichever thread > the OS decides to schedule next. I don't think there > is any guarantee that that will be the one the user > was previously looking at. I think the OS scheduler is not really relevant here. GDB assumes it can decide which of the threads of an application it wants to *single-step*. So if an application has threads A, B, and C, and is stopped on an event in B, and then decides it wants to continue single-stepping C, it will tell the target to continue all thread, while single-stepping C. Now the OS scheduler may choose to run A, B, or C next (or several of them in parallel on an SMP system), but no matter what: we should never get single-step events from A or B, but we should get a single-step event after C has executed its first instruction (whenever that may be). The above assumption (that GDB can decide which threads to single-step) is always true when using software single- stepping. It is also true for the Linux native target, and for the remote target (assuming the remote side implements the protocol accordingly). There may be odd targets where this assumption is false; GDB will probably get confused on those. Bye, Ulrich -- Dr. Ulrich Weigand GNU Toolchain for Linux on System z and Cell BE Ulrich.Weigand@de.ibm.com