From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 7204 invoked by alias); 24 Jan 2006 14:22:59 -0000 Received: (qmail 7188 invoked by uid 22791); 24 Jan 2006 14:22:57 -0000 X-Spam-Check-By: sourceware.org Received: from zigzag.lvk.cs.msu.su (HELO zigzag.lvk.cs.msu.su) (158.250.17.23) by sourceware.org (qpsmtpd/0.31) with ESMTP; Tue, 24 Jan 2006 14:22:56 +0000 Received: from Debian-exim by zigzag.lvk.cs.msu.su with spam-scanned (Exim 4.50) id 1F1P4L-0005YV-1t for gdb@sources.redhat.com; Tue, 24 Jan 2006 17:22:52 +0300 Received: from zigzag.lvk.cs.msu.su ([158.250.17.23]) by zigzag.lvk.cs.msu.su with esmtp (Exim 4.50) id 1F1P4K-0005YH-Vs for gdb@sources.redhat.com; Tue, 24 Jan 2006 17:22:49 +0300 From: Vladimir Prus To: gdb@sources.redhat.com Subject: Re: Multithreaded debugging: strange thread switches Date: Tue, 24 Jan 2006 14:28:00 -0000 User-Agent: KMail/1.7.2 References: <200601231820.33372.ghost@cs.msu.su> <20060123155240.GA16524@nevyn.them.org> In-Reply-To: <20060123155240.GA16524@nevyn.them.org> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200601241722.48386.ghost@cs.msu.su> 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/msg00232.txt.bz2 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? > > "Hc2", and in infrun.c, function prepare_to_proceed, I see this: > > > > > > if (!ptid_equal (wait_ptid, minus_one_ptid) > > && !ptid_equal (inferior_ptid, wait_ptid)) > > { > > /* Switched over from WAIT_PID. */ > > CORE_ADDR wait_pc = read_pc_pid (wait_ptid); > > > > if (wait_pc != read_pc ()) > > { > > /* Switch back to WAIT_PID thread. */ > > inferior_ptid = wait_ptid; > > > > /* FIXME: This stuff came from switch_to_thread() in > > thread.c (which should probably be a public function). */ > > flush_cached_frames (); > > registers_changed (); > > stop_pc = wait_pc; > > select_frame (get_current_frame ()); > > } > > > > Can somebody explain the reason for this explicit switch back to > > "wait_ptid"? > > I have no idea, but if you remove it you're going to bust the bit below > that steps over breakpoints, and then GDB will really get unhappy. > Maybe we can adjust that block of code, though. See the comment in > proceed(): > > /* In a multi-threaded task we may select another thread > and then continue or step. > > But if the old thread was stopped at a breakpoint, it > will immediately cause another breakpoint stop without > any execution (i.e. it will report a breakpoint hit > incorrectly). So we must step over it first. > > prepare_to_proceed checks the current thread against the thread > that reported the most recent event. If a step-over is required > it returns TRUE and sets the current thread to the old thread. */ I see. But after we've single-stepped over breakpoint, will we switch back to the thread where "next" was issued? > 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. > Previously the thread would only be switched if (SIGTRAP && breakpoint > here). Now it's switched if (SIGTRAP || SIGINT) and then we > single-step if (breakpoint here). Which doesn't make much sense. I've tried to revert that patch and rerun the testsuite, and got quite a bunch of extra errors. I'll look deeper later. - Volodya