From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 4608 invoked by alias); 30 Mar 2009 18:42:10 -0000 Received: (qmail 4596 invoked by uid 22791); 30 Mar 2009 18:42:10 -0000 X-SWARE-Spam-Status: No, hits=-1.7 required=5.0 tests=AWL,BAYES_00,MSGID_FROM_MTA_HEADER,SPF_PASS X-Spam-Check-By: sourceware.org Received: from mtagate5.de.ibm.com (HELO mtagate5.de.ibm.com) (195.212.29.154) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Mon, 30 Mar 2009 18:42:03 +0000 Received: from d12nrmr1607.megacenter.de.ibm.com (d12nrmr1607.megacenter.de.ibm.com [9.149.167.49]) by mtagate5.de.ibm.com (8.14.3/8.13.8) with ESMTP id n2UIeoL0320610 for ; Mon, 30 Mar 2009 18:40:50 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.2) with ESMTP id n2UIeoQ82494472 for ; Mon, 30 Mar 2009 20:40:50 +0200 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 n2UIen4A018442 for ; Mon, 30 Mar 2009 20:40:50 +0200 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 n2UIemX1018434; Mon, 30 Mar 2009 20:40:48 +0200 Message-Id: <200903301840.n2UIemX1018434@d12av02.megacenter.de.ibm.com> Received: by tuxmaker.boeblingen.de.ibm.com (sSMTP sendmail emulation); Mon, 30 Mar 2009 20:40:48 +0200 Subject: Re: [RFA] Fix hand called function when another thread has hit a bp. To: dje@google.com (Doug Evans) Date: Mon, 30 Mar 2009 18:48:00 -0000 From: "Ulrich Weigand" Cc: gdb-patches@sourceware.org (gdb-patches) In-Reply-To: from "Doug Evans" at Feb 23, 2009 05:32:38 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: 2009-03/txt/msg00682.txt.bz2 Doug Evans wrote: > Hi. Here's an updated version of the patch. Sorry for the late reply on this! > Handling the restart after several threads are all stopped at a > breakpoint (via scheduler-locking = 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? That is to say, in the scenario where we have - set scheduler-locking on - stop on BP in thread A - manually switch to thread B - continue execution the behaviour today is: - GDB will switch back to A and single-step - (correctly) bypass the already-hit breakpoint in A - (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: - GDB (correctly) continues execution of thread B - but the next time thread A is run, GDB will (incorrectly) 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? >+for { set i 1 } { $i <= $total_nr_threads } { incr i } { >+ set thread_nr $i >+ gdb_test "thread $thread_nr" "" "prepare to discard hand call, thread $thread_nr" >+ set frame_number [get_dummy_frame_number] >+ if { "$frame_number" == "" } { >+ fail "dummy stack frame number, thread $thread_nr" >+ setup_xfail "*-*-*" >+ # Need something. >+ set frame_number 0 Why do we need this xfail here? >+# Continue one last time, the program should exit normally. >+# >+# ??? This currently doesn't work because gdb doesn't know how to singlestep >+# 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 run, >+# 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? It seems to me this was just an unsuccessful attempt to work-around the bug ... Otherwise, the patch is OK. Thanks, Ulrich -- Dr. Ulrich Weigand GNU Toolchain for Linux on System z and Cell BE Ulrich.Weigand@de.ibm.com