From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 21068 invoked by alias); 3 Apr 2009 23:25:42 -0000 Received: (qmail 21052 invoked by uid 22791); 3 Apr 2009 23:25:40 -0000 X-SWARE-Spam-Status: No, hits=-1.8 required=5.0 tests=AWL,BAYES_00,SARE_MSGID_LONG40,SPF_PASS X-Spam-Check-By: sourceware.org Received: from smtp-out.google.com (HELO smtp-out.google.com) (216.239.33.17) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Fri, 03 Apr 2009 23:25:33 +0000 Received: from wpaz13.hot.corp.google.com (wpaz13.hot.corp.google.com [172.24.198.77]) by smtp-out.google.com with ESMTP id n33NPSRf020313 for ; Sat, 4 Apr 2009 00:25:29 +0100 Received: from rv-out-0506.google.com (rvfb25.prod.google.com [10.140.179.25]) by wpaz13.hot.corp.google.com with ESMTP id n33NPQ0g003126 for ; Fri, 3 Apr 2009 16:25:26 -0700 Received: by rv-out-0506.google.com with SMTP id b25so1442748rvf.55 for ; Fri, 03 Apr 2009 16:25:26 -0700 (PDT) MIME-Version: 1.0 Received: by 10.141.176.4 with SMTP id d4mr761515rvp.253.1238801126313; Fri, 03 Apr 2009 16:25:26 -0700 (PDT) In-Reply-To: <200903301840.n2UIemX1018434@d12av02.megacenter.de.ibm.com> References: <200903301840.n2UIemX1018434@d12av02.megacenter.de.ibm.com> Date: Fri, 03 Apr 2009 23:25: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 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-System-Of-Record: true 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: 2009-04/txt/msg00089.txt.bz2 On Mon, Mar 30, 2009 at 11:40 AM, Ulrich Weigand wrot= e: > Doug Evans wrote: > >> Hi. =A0Here's an updated version of the patch. > > Sorry for the late reply on this! No worries. >> Handling the restart after several threads are all stopped at a >> breakpoint (via scheduler-locking =3D on), is left for a later patch >> (it's happens more rarely). > > This patch, as far as I can see, just replaces one incorrect > behaviour with a different incorrect behaviour, right? One could look at it that way. I look at it as taking one step of a two step fix. :-) > That is to say, in the scenario where we have > > =A0- set scheduler-locking on > =A0- stop on BP in thread A > =A0- manually switch to thread B > =A0- continue execution > > the behaviour today is: > > =A0- GDB will switch back to A and single-step > =A0- (correctly) bypass the already-hit breakpoint in A > =A0- (incorrectly) continue execution thread A > > i.e. the incorrect behaviour is that thread A is continued, > and not thread B. > > With your patch, the behaviour is: > > =A0- GDB (correctly) continues execution of thread B > =A0- but the next time thread A is run, GDB will (incorrectly) > =A0 report a second time the same breakpoint the user already saw > > Did I miss anything here? > > In any case, I guess I agree that the "new" type of incorrect > behaviour is probably less bad that what we have today, so > your patch does seem to be a step forward. > > Will you be working on a follow-on patch to fix the new > incorrect behaviour? That's the plan. It involves recording the stop reason for every thread, and appropriately applying it when resuming. > >>+for { set i 1 } { $i <=3D $total_nr_threads } { incr i } { >>+ =A0 =A0set thread_nr $i >>+ =A0 =A0gdb_test "thread $thread_nr" "" "prepare to discard hand call, t= hread $thread_nr" >>+ =A0 =A0set frame_number [get_dummy_frame_number] >>+ =A0 =A0if { "$frame_number" =3D=3D "" } { >>+ =A0 =A0 =A0fail "dummy stack frame number, thread $thread_nr" >>+ =A0 =A0 =A0setup_xfail "*-*-*" >>+ =A0 =A0 =A0# Need something. >>+ =A0 =A0 =A0set frame_number 0 > > Why do we need this xfail here? It's not needed. I can remove it. >>+# Continue one last time, the program should exit normally. >>+# >>+# ??? This currently doesn't work because gdb doesn't know how to single= step >>+# over reported breakpoints that weren't in the last thread to run. >>+# Fixing this first requires defining what the correct behaviour is. >>+# Commented out until then. >>+# >>+# Manually set the thread back to the first thread: the program is still= at >>+# the all_threads_running breakpoint, which wasn't the last thread to ru= n, >>+# and gdb doesn't know how to singlestep over reported breakpoints that >>+# weren't in the last thread to run. >>+#gdb_test "thread 1" "" "set thread to 1, prepare to resume" >>+# >>+#gdb_continue_to_end "hand-call-in-threads" > > Should the "thread 1" really be here? =A0It seems to me this was just an > unsuccessful attempt to work-around the bug ... It's there to document the bug (until it's fixed). > Otherwise, the patch is OK.