From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 23834 invoked by alias); 28 Jun 2013 14:24:00 -0000 Mailing-List: contact gdb-prs-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-prs-owner@sourceware.org Received: (qmail 23801 invoked by uid 48); 28 Jun 2013 14:23:59 -0000 From: "palves at redhat dot com" To: gdb-prs@sourceware.org Subject: [Bug breakpoints/15693] Extra *running event when call-style dprintf hits Date: Fri, 28 Jun 2013 14:24:00 -0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: gdb X-Bugzilla-Component: breakpoints X-Bugzilla-Version: HEAD X-Bugzilla-Keywords: X-Bugzilla-Severity: normal X-Bugzilla-Who: palves at redhat dot com X-Bugzilla-Status: NEW X-Bugzilla-Priority: P2 X-Bugzilla-Assigned-To: unassigned at sourceware dot org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-Bugzilla-URL: http://sourceware.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-SW-Source: 2013-q2/txt/msg00546.txt.bz2 http://sourceware.org/bugzilla/show_bug.cgi?id=15693 --- Comment #3 from Pedro Alves --- > That is interesting. If there is an infcall that causes a bp to be skipped, > we see this extra *running event. > But if it is not an infcall and the bp is still skipped (due to some other > condition), we don't see the event. Indeed. We also have: static void mi_on_resume (ptid_t ptid) { struct thread_info *tp = NULL; if (ptid_equal (ptid, minus_one_ptid) || ptid_is_pid (ptid)) tp = inferior_thread (); else tp = find_thread_ptid (ptid); /* Suppress output while calling an inferior function. */ if (tp->control.in_infcall) return; In the non-infcall case, the thread is never marked THREAD_STOPPED, so set_running never ends up letting the MI observer known a thread was started. However, if an infcall is involved, then when the infcall finishes, the normal_stop ends up making the thread state be THREAD_STOPPED: (top-gdb) bt #0 0x00000000005dfc87 in finish_thread_state (ptid=...) at ../../src/gdb/thread.c:723 #1 0x00000000005dfdcf in finish_thread_state_cleanup (arg=0xc51a00) at ../../src/gdb/thread.c:750 #2 0x0000000000571474 in do_my_cleanups (pmy_chain=0xc4c630, old_chain=0xf194c0) at ../../src/gdb/cleanups.c:155 #3 0x00000000005714e1 in do_cleanups (old_chain=0xf194c0) at ../../src/gdb/cleanups.c:177 #4 0x00000000005d3476 in normal_stop () at ../../src/gdb/infrun.c:6040 #5 0x00000000005cbb12 in proceed (addr=18446744073709551615, siggnal=GDB_SIGNAL_DEFAULT, step=0) at ../../src/gdb/infrun.c:2342 #6 0x00000000005c3e24 in continue_1 (all_threads=0) at ../../src/gdb/infcmd.c:726 #7 0x00000000005c409b in continue_command (args=0x0, from_tty=1) at ../../src/gdb/infcmd.c:818 #8 0x00000000004dc5cf in do_cfunc (c=0xd380b0, args=0x0, from_tty=1) at ../../src/gdb/cli/cli-decode.c:113 #9 0x00000000004df664 in cmd_func (cmd=0xd380b0, args=0x0, from_tty=1) at ../../src/gdb/cli/cli-decode.c:1888 #10 0x00000000006e4425 in execute_command (p=0x7fffffffd341 "", from_tty=1) at ../../src/gdb/top.c:489 However, we don't want that in an infcall -- from the frontend's and user's perspective the thread was nver THREAD_STOPPED. Sounds like then the fix is to do the suppressing in the normal_stop/THREAD_STOPPED path, not on the "set_running" path. -- You are receiving this mail because: You are on the CC list for the bug.