From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 20476 invoked by alias); 15 Dec 2008 22:07:16 -0000 Received: (qmail 20468 invoked by uid 22791); 15 Dec 2008 22:07:15 -0000 X-Spam-Check-By: sourceware.org Received: from smtp-out.google.com (HELO smtp-out.google.com) (216.239.45.13) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Mon, 15 Dec 2008 22:06:40 +0000 Received: from spaceape10.eur.corp.google.com (spaceape10.eur.corp.google.com [172.28.16.144]) by smtp-out.google.com with ESMTP id mBFM6bn4022193 for ; Mon, 15 Dec 2008 14:06:38 -0800 Received: from rv-out-0708.google.com (rvbl33.prod.google.com [10.140.88.33]) by spaceape10.eur.corp.google.com with ESMTP id mBFM6Z2X012899 for ; Mon, 15 Dec 2008 14:06:35 -0800 Received: by rv-out-0708.google.com with SMTP id l33so3147313rvb.58 for ; Mon, 15 Dec 2008 14:06:34 -0800 (PST) MIME-Version: 1.0 Received: by 10.141.142.15 with SMTP id u15mr3957054rvn.16.1229378794667; Mon, 15 Dec 2008 14:06:34 -0800 (PST) In-Reply-To: <200812142213.mBEMDAFX019852@d12av02.megacenter.de.ibm.com> References: <200812142213.mBEMDAFX019852@d12av02.megacenter.de.ibm.com> Date: Mon, 15 Dec 2008 22:07:00 -0000 Message-ID: Subject: Re: [RFA] Fix hand called function when another thread has hit a bp. From: Doug Evans To: Ulrich Weigand Cc: gdb-patches@sourceware.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-IsSubscribed: yes 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-12/txt/msg00293.txt.bz2 On Sun, Dec 14, 2008 at 2:13 PM, Ulrich Weigand wrote: > Doug Evans wrote: > >> >> Adding the above to the end of the testcase reveals the fact that this >> >> patch causes gdb to lose track of the fact that it needs to single >> >> step over the breakpoint at all_threads_running in the main thread, >> >> and resuming execution causes the breakpoint to be hit again. Global >> >> state, gotta love it. >> >> >> >> I'm assuming non-stop mode doesn't have this problem. >> >> Can we record in struct thread_info (or some such) the last stop >> >> reason and before resuming with !scheduler-locking iterate over all >> >> threads, single stepping them as necessary? Is there a better >> >> solution? >> > >> > This patch fixes the expanded hand-call-in-threads.exp testcase (which >> > is part of the patch). In the process I discovered a bigger problem - >> > gdb doesn't handle resuming after more than one thread is stopped at a >> > breakpoint. This can happen if the user runs several threads in turn >> > with scheduler-locking on, and then turns scheduler-locking off and >> > resumes the program. I wrote another testcase, >> > multi-bp-in-threads.exp, to expose this issue. Fixing this appears to >> > be a much harder problem, and I think I'd like to declare partial >> > victory with this patch ... > > I'm not sure this is the right approach -- how can we be sure those > breakpoints in other threads have already been reported to the user? Hmm, do we need a flag that says which signals have been reported? > The original code specifically steps only over the one breakpoint that > was reported when GDB last stopped. If other threads hit breakpoints > simultaneously, we *want* them to trigger again, so that they can be > properly reported to the user ... > > Why does this not work for your test case? Hmm, I think we need to distinguish which testcase we're talking about. hand-call-in-threads.exp: What it does: - start up N threads and stop - set scheduler-locking on - hand-call a function in N threads, each of which hits a breakpoint - manually pop pending dummy frames - set scheduler-locking off - continue What it tests: - verify a previously hit breakpoint in a different thread is NOT singlestepped when resuming with scheduler-locking on - verify manually popping all pending dummy frames works - verify that resuming after manually popping all pending dummy frames works (i.e. a previously hit and reported breakpoint is not re-reported) multi-bp-in-threads.exp: What it does: - start up N threads and stop - set scheduler-locking on - hand-call a function in N threads, each of which hits a breakpoint - set scheduler-locking off - continue What it tests: - see what happens ... it's not clear to me what _should_ happen here Perhaps first we should agree on what the right behavior is. For hand-call-in-threads.exp I think the testcase is correct as is. For multi-bp-in-threads.exp, one approach is to just define the problem away and say that GDB's current behavior is the correct behavior. :)