aboutsummaryrefslogtreecommitdiff
path: root/gdb/target.c
diff options
context:
space:
mode:
authorPedro Alves <palves@redhat.com>2014-05-29 12:27:01 +0100
committerPedro Alves <palves@redhat.com>2014-05-29 12:27:01 +0100
commit251bde03baf93dbb44d3785e09e03179916143e3 (patch)
treec4d4fd7b6df5cc684d7d4cbca655a6879237b221 /gdb/target.c
parent434415618f6bb9ac428a8d18ab33111920cd04dc (diff)
downloadgdb-251bde03baf93dbb44d3785e09e03179916143e3.zip
gdb-251bde03baf93dbb44d3785e09e03179916143e3.tar.gz
gdb-251bde03baf93dbb44d3785e09e03179916143e3.tar.bz2
PR15693 - Fix spurious *running events, thread state, dprintf-style call
If one sets a breakpoint with a condition that involves calling a function in the inferior, and then the condition evaluates false, GDB outputs one *running event for each time the program hits the breakpoint. E.g., $ 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=(...) (gdb) *running,thread-id=(...) *running,thread-id=(...) *running,thread-id=(...) *running,thread-id=(...) *running,thread-id=(...) ... repeat forever ... An easy way a user can trip on this is with a dprintf with "set dprintf-style call". In that case, a dprintf is just a breakpoint that when hit GDB calls the printf function in the inferior, and then resumes it, just like the case above. If the breakpoint/dprintf is set in a loop, then these spurious events can potentially slow down a frontend much, if it decides to refresh its GUI whenever it sees this event (Eclipse is one such case). When we run an infcall, we pretend we don't actually run the inferior. This is already handled for the usual case of calling a function directly from the CLI: (gdb) p return_false () &"p return_false ()\n" ~"$1 = 0" ~"\n" ^done (gdb) Note no *running, nor *stopped events. That's handled by: static void mi_on_resume (ptid_t ptid) { ... /* Suppress output while calling an inferior function. */ if (tp->control.in_infcall) return; and equivalent code on normal_stop. However, in the cases of the PR, after finishing the infcall there's one more resume, and mi_on_resume doesn't know that it should suppress output then too, somehow. The "running/stopped" state is a high level user/frontend state. Internal stops are invisible to the frontend. If follows from that that we should be setting the thread to running at a higher level where we still know the set of threads the user _intends_ to resume. Currently we mark a thread as running from within target_resume, a low level target operation. As consequence, today, if we resume a multi-threaded program while stopped at a breakpoint, we see this: -exec-continue ^running *running,thread-id="1" (gdb) *running,thread-id="all" The first *running was GDB stepping over the breakpoint, and the second is GDB finally resuming everything. Between those two *running's, threads other than "1" still have their state set to stopped. That's bogus -- in async mode, this opens a tiny window between both resumes where the user might try to run another execution command to threads other than thread 1, and very much confuse GDB. That is, the "step" below should fail the "step", complaining that the thread is running: (gdb) c -a & (gdb) thread 2 (gdb) step IOW, threads that GDB happens to not resume immediately (say, because it needs to step over a breakpoint) shall still be marked as running. Then, if we move marking threads as running to a higher layer, decoupled from target_resume, plus skip marking threads as running when running an infcall, the spurious *running events disappear, because there will be no state transitions at all. I think we might end up adding a new thread state -- THREAD_INFCALL or some such, however since infcalls are always synchronous today, I didn't find a need. There's no way to execute a CLI/MI command directly from the prompt if some thread is running an infcall. Tested on x86_64 Fedora 20. gdb/ 2014-05-29 Pedro Alves <palves@redhat.com> PR PR15693 * infrun.c (resume): Determine how much to resume depending on whether the caller wanted a step, not whether we can hardware step the target. Mark all threads that we intend to run as running, unless we're calling an inferior function. (normal_stop): If the thread is running an infcall, don't finish thread state. * target.c (target_resume): Don't mark threads as running here. gdb/testsuite/ 2014-05-29 Pedro Alves <palves@redhat.com> Hui Zhu <hui@codesourcery.com> PR PR15693 * gdb.mi/mi-condbreak-call-thr-state-mt.c: New file. * gdb.mi/mi-condbreak-call-thr-state-st.c: New file. * gdb.mi/mi-condbreak-call-thr-state.c: New file. * gdb.mi/mi-condbreak-call-thr-state.exp: New file.
Diffstat (limited to 'gdb/target.c')
-rw-r--r--gdb/target.c3
1 files changed, 2 insertions, 1 deletions
diff --git a/gdb/target.c b/gdb/target.c
index cf86e73..6a1a2ff 100644
--- a/gdb/target.c
+++ b/gdb/target.c
@@ -2150,8 +2150,9 @@ target_resume (ptid_t ptid, int step, enum gdb_signal signal)
gdb_signal_to_name (signal));
registers_changed_ptid (ptid);
+ /* We only set the internal executing state here. The user/frontend
+ running state is set at a higher level. */
set_executing (ptid, 1);
- set_running (ptid, 1);
clear_inline_frame_state (ptid);
}