With HEAD of June 27 which has the fix to Bug 15075, I'm seeing an un-expected *running event each time a dprintf is hit in the dprintf-style 'call'. Here is an cleaned up session showing the problem: > gdb.7.7 -i mi loopfirst =thread-group-added,id="i1" ~"GNU gdb (GDB) 7.6.50.20130627-cvs\n" (gdb) -dprintf-insert 8 "hello\n" ^done,bkpt={number="1",type="dprintf",disp="keep",enabled="y",addr="0x0000000000400570",func="main()",file="loopfirst.cc",fullname="/home/lmckhou/testing/loopfirst.cc",line="8",thread-groups=["i1"],times="0",script={"printf \"hello\\n\""},original-location="/home/lmckhou/testing/loopfirst.cc:8"} (gdb) set dprintf-style call &"set dprintf-style call\n" =breakpoint-modified,bkpt={number="1",type="dprintf",disp="keep",enabled="y",addr="0x0000000000400570",func="main()",file="loopfirst.cc",fullname="/home/lmckhou/testing/loopfirst.cc",line="8",thread-groups=["i1"],times="0",script={"call (void) printf (\\"hello\\\\n\\")"},original-location="/home/lmckhou/testing/loopfirst.cc:8"} =cmd-param-changed,param="dprintf-style",value="call" ^done (gdb) -exec-run =thread-group-started,id="i1",pid="6627" =thread-created,id="1",group-id="i1" ^running *running,thread-id="all" (gdb) [...] =breakpoint-modified,bkpt={number="1",type="dprintf",disp="keep",enabled="y",addr="0x0000000000400570",func="main()",file="loopfirst.cc",fullname="/home/lmckhou/testing/loopfirst.cc",line="8",thread-groups=["i1"],times="1",script={"call (void) printf (\\"hello\\\\n\\")"},original-location="/home/lmckhou/testing/loopfirst.cc:8"} hello *running,thread-id="1" => we can see this extra *running event, which is not seen when using the 'gdb' dprintf-style.
Yeah, you'll this for all infcalls, not just dprintf+call. E.g., with something like: #include <unistd.h> #include <stdlib.h> int return_false (void) { return 0; } int main () { while (1) usleep (1); } $ gdb return-false -i=mi (gdb) start ... (gdb) b 14 if return_false () &"b 14 if return_false ()\n" ~"Breakpoint 2 at 0x4004eb: file return-false.c, line 14.\n" ... ^done (gdb) c &"c\n" ~"Continuing.\n" ^running *running,thread-id="1" (gdb) *running,thread-id="1" *running,thread-id="1" *running,thread-id="1" *running,thread-id="1" *running,thread-id="1" *running,thread-id="1" ... repeat forever ... We should be suppressing that if we never told the user/frontend the thread was stopped.
(In reply to Pedro Alves from comment #1) > Yeah, you'll this for all infcalls, not just dprintf+call. [...] >(gdb) b 14 if return_false () 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. > We should be suppressing that if we never told the user/frontend the thread > was stopped. Nicer. Thanks.
> 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.
http://sourceware.org/ml/gdb-patches/2013-07/msg00222.html
Fixed: https://sourceware.org/ml/gdb-patches/2014-05/msg00273.html