From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 11473 invoked by alias); 24 Jan 2006 14:28:52 -0000 Received: (qmail 11463 invoked by uid 22791); 24 Jan 2006 14:28:52 -0000 X-Spam-Check-By: sourceware.org Received: from nevyn.them.org (HELO nevyn.them.org) (66.93.172.17) by sourceware.org (qpsmtpd/0.31.1) with ESMTP; Tue, 24 Jan 2006 14:28:49 +0000 Received: from drow by nevyn.them.org with local (Exim 4.54) id 1F1PA6-000402-LH; Tue, 24 Jan 2006 09:28:47 -0500 Date: Tue, 24 Jan 2006 14:41:00 -0000 From: Daniel Jacobowitz To: Vladimir Prus Cc: gdb@sources.redhat.com Subject: Re: Multithreaded debugging: strange thread switches Message-ID: <20060124142846.GA15268@nevyn.them.org> Mail-Followup-To: Vladimir Prus , gdb@sources.redhat.com References: <200601231820.33372.ghost@cs.msu.su> <20060123155240.GA16524@nevyn.them.org> <200601241722.48386.ghost@cs.msu.su> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200601241722.48386.ghost@cs.msu.su> User-Agent: Mutt/1.5.8i X-IsSubscribed: yes Mailing-List: contact gdb-help@sourceware.org; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sourceware.org X-SW-Source: 2006-01/txt/msg00233.txt.bz2 On Tue, Jan 24, 2006 at 05:22:47PM +0300, Vladimir Prus wrote: > On Monday 23 January 2006 18:52, Daniel Jacobowitz wrote: > > > > I'm observing strange behaviour when debugging with gdb using a custom > > > stub. I have two threads. After connecting, I say "next" several times > > > and that steps in thread 1. Then I say "thread 2" and "next". Gdb then > > > stops again in thread 1, not in thread 2 as I'd expected. > > > > > > In the remote protocol I see "Hc1" packet after last "next" though I'd > > > expect > > > > This, generally, is part of the problem. If you want this to work, you > > need to implement the vCont packet in the stub. The Hc1 packet is > > supposed to mean "step only thread 1, leaving thread 2 stopped", and > > that's not what the gdb "next" command is supposed to map to - that's > > "step this thread but leave other threads free-running". > > Well, strictly speaking I want "next" to mean "move this thread to next source > line, then single-step all other threads until there are at the same time as > the current thread". (The remote side is sumulator, so "same time" is > well-defined). > > I do not think that vCont can exactly express what I want, so there's always > be some difference between what gdb says over remote connection and what I > want to be done -- are you sure using vCont will be any better? Well, GDB doesn't have any command that it expects to have that behavior. If you want GDB to do that, I recommend adding such an interface. From what I can see, you can get the same effect by "single step all threads in sync, repeatedly, until this thread reaches the next source line", which is "vCont;s", or possibly "Hc-1" "s" - not completely sure about the last one, the documentation suggests that's right, but I don't know any stub that handles either of these correctly. > I see. But after we've single-stepped over breakpoint, will we switch back to > the thread where "next" was issued? At the moment, no. This is definitely a bug but it's a pretty nasty infrun limitation; really that whole subsystem needs some love and attention. > > The current code was modified to always select the previous thread > > in arch-utils.c revision 1.28 in order to support resuming after > > hitting Control-C: > > http://sourceware.org/ml/gdb-patches/2001-05/msg00419.html > > > > I can't tell from Jonathan's post what problem he's trying to fix. > > Hmmm, maybe that's a sign that Changelog requirements are suboptimal? Most > often, Changelog entries contain lots of details about > changes to specific functions, but no general overview of the goal of the > patch. No, the mailing list archives are where this sort of thing is supposed to live - and the comments in the code. See the GNU coding standards and their description of what goes in a changelog entry. Sometimes very strange, but that's what we've got to work with. -- Daniel Jacobowitz CodeSourcery