From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 30608 invoked by alias); 24 Jan 2006 15:02:13 -0000 Received: (qmail 30593 invoked by uid 22791); 24 Jan 2006 15:02:12 -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 15:02:11 +0000 Received: from drow by nevyn.them.org with local (Exim 4.54) id 1F1PgO-0004D6-Jv for gdb@sourceware.org; Tue, 24 Jan 2006 10:02:08 -0500 Date: Tue, 24 Jan 2006 16:16:00 -0000 From: Daniel Jacobowitz To: gdb@sourceware.org Subject: Re: Multithreaded debugging: strange thread switches Message-ID: <20060124150208.GA16048@nevyn.them.org> Mail-Followup-To: gdb@sourceware.org References: <200601231820.33372.ghost@cs.msu.su> <200601241722.48386.ghost@cs.msu.su> <20060124142846.GA15268@nevyn.them.org> <200601241741.45231.ghost@cs.msu.su> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200601241741.45231.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/msg00237.txt.bz2 On Tue, Jan 24, 2006 at 05:41:44PM +0300, Vladimir Prus wrote: > > 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", > > Generally speaking if 2 threads execute 10 steps each, they no longer are at > the same time, because instructions in thread 1 can take one cycle each, > while instructions in thread can take two cycles each. I'd prefer this > synchronization logic to be inside my remote part, which is specifialized for > that task. I think that adds weight to my argument that the existing GDB commands don't correspond to this action :-) There's a documented (but never implemented, as far as I know) 'i' packet to step a single cycle. And the vCont mechanism is extensible for new continue operations (deliberately). So you could make GDB do exactly what you want in at least two ways: 1. vCont;TID:s until at the next line query time vCont;TID:0;i until times match (where 0 means "stopped" and "i" means "one cycle") 2. vCont;i until at the next line I'd recommend #2 unless you have some reason not to do that. > > 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. > > Is that bug filed in the bug tracker? Should I file it? I don't know; you might as well. I think the case described above might actually work, but there are definitely some gotchas in this area. > But if I'm looking at Changelog entry, how can I guess the subject of email > that discusses this change? You have the date; in practice, it never takes me more than a couple of minutes. Please, take further discussion of the ChangeLog convention to a more appropriate forum - it's the GNU standard. -- Daniel Jacobowitz CodeSourcery