From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 3558 invoked by alias); 14 Dec 2008 22:14:07 -0000 Received: (qmail 3548 invoked by uid 22791); 14 Dec 2008 22:14:07 -0000 X-Spam-Check-By: sourceware.org Received: from mtagate4.de.ibm.com (HELO mtagate4.de.ibm.com) (195.212.29.153) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Sun, 14 Dec 2008 22:13:13 +0000 Received: from d12nrmr1607.megacenter.de.ibm.com (d12nrmr1607.megacenter.de.ibm.com [9.149.167.49]) by mtagate4.de.ibm.com (8.13.8/8.13.8) with ESMTP id mBEMDAIf101612 for ; Sun, 14 Dec 2008 22:13:10 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.1) with ESMTP id mBEMDAmX3534976 for ; Sun, 14 Dec 2008 23:13:10 +0100 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 mBEMDAoh019855 for ; Sun, 14 Dec 2008 23:13:10 +0100 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 mBEMDAFX019852; Sun, 14 Dec 2008 23:13:10 +0100 Message-Id: <200812142213.mBEMDAFX019852@d12av02.megacenter.de.ibm.com> Received: by tuxmaker.boeblingen.de.ibm.com (sSMTP sendmail emulation); Sun, 14 Dec 2008 23:13:10 +0100 Subject: Re: [RFA] Fix hand called function when another thread has hit a bp. To: dje@google.com (Doug Evans) Date: Sun, 14 Dec 2008 22:14:00 -0000 From: "Ulrich Weigand" Cc: gdb-patches@sourceware.org In-Reply-To: from "Doug Evans" at Dec 14, 2008 01:59:29 PM 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-12/txt/msg00268.txt.bz2 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? 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? Bye, Ulrich -- Dr. Ulrich Weigand GNU Toolchain for Linux on System z and Cell BE Ulrich.Weigand@de.ibm.com