diff options
| author | Pedro Alves <palves@redhat.com> | 2014-10-02 09:55:38 +0100 |
|---|---|---|
| committer | Pedro Alves <palves@redhat.com> | 2014-10-02 09:55:38 +0100 |
| commit | 32990adaadc1b119700cd0dfd2dd8849114e0135 (patch) | |
| tree | 2d9c197dc5bd9234d2b98078e19540696dadc241 /gdb/inferior.c | |
| parent | dac3fe877844e76de9cf102151837998aa1d2a8f (diff) | |
| download | binutils-gdb-32990adaadc1b119700cd0dfd2dd8849114e0135.tar.gz | |
Reduce Hg packet (select remote general thread) bouncing
A patch I wrote made GDB pull the thread list sooner when debugging
with target remote, and I noticed an intended consequence. GDB
started bouncing around the currently selected remote/general thread
more frequently. E.g.:
Sending packet: $qTMinFTPILen#3b...Packet received: 5
+Sending packet: $Hgp726d.726d#53...Packet received: OK
Sending packet: $m400680,40#2f...Packet received: 85c0741455bff00d60004889e5ffd05de97bffffff0f1f00e973ffffff0f1f00554889e5c745fc00000000c745fc01000000e900000000c745fc02000000b800
+Sending packet: $Hgp726d.7278#28...Packet received: OK
Sending packet: $m4006b2,1#28...Packet received: e9
Fast tracepoint 2 at 0x4006b2: file gdb/testsuite/gdb.trace/range-stepping.c, line 53.
Sending packet: $qTStatus#49...Packet received: T0;tnotrun:0;tframes:0;tcreated:0;tfree:500000;tsize:500000;circular:0;disconn:0;starttime:0;stoptime:0;username:;notes::
This ended up breaking "tstart" when one has fast tracepoints set,
because gdbserver isn't expecting an Hg packet in response to
qRelocInsn:
(gdb) ftrace *set_point
Fast tracepoint 3 at 0x4006b2: file gdb/testsuite/gdb.trace/range-stepping.c, line 53.
(gdb) PASS: gdb.trace/range-stepping.exp: ftrace: ftrace *set_point
tstart
gdbserver: Malformed response to qRelocInsn, ignoring: Hgp2783.2783
Target does not support this command.
(gdb) FAIL: gdb.trace/range-stepping.exp: ftrace: tstart
remote_trace_start should probably start by making sure the remote
current thread matches inferior_ptid (calling set_general_thread), but
still, reducing unnecessary bouncing is a good idea. It happens
because the memory/symbol/breakpoint routines use
switch_to_program_space_and_thread to do something in the right
context and then revert back to the previously current thread.
The fix is to simply make any_thread_of_process,
find_inferior_for_program_space, etc. give preference to the current
thread/inferior it if matches.
gdb/
2014-10-02 Pedro Alves <palves@redhat.com>
* gdbthread.h (any_thread_of_process, any_live_thread_of_process):
Adjust comments.
* inferior.c (find_inferior_for_program_space): Give preference to
the current inferior.
* inferior.h (find_inferior_for_program_space): Update comment.
* progspace.c (switch_to_program_space_and_thread): Prefer the
current inferior if it's bound to the program space requested. If
the inferior found doesn't have a PID yet, don't bother looking up
a thread.
* progspace.h (switch_to_program_space_and_thread): Adjust
comment.
* thread.c (any_thread_of_process, any_live_thread_of_process):
Give preference to the current thread.
Diffstat (limited to 'gdb/inferior.c')
| -rw-r--r-- | gdb/inferior.c | 7 |
1 files changed, 5 insertions, 2 deletions
diff --git a/gdb/inferior.c b/gdb/inferior.c index 66401ab99bd..44f456001d5 100644 --- a/gdb/inferior.c +++ b/gdb/inferior.c @@ -367,12 +367,15 @@ find_inferior_pid (int pid) return NULL; } -/* Find an inferior bound to PSPACE. */ +/* See inferior.h. */ struct inferior * find_inferior_for_program_space (struct program_space *pspace) { - struct inferior *inf; + struct inferior *inf = current_inferior (); + + if (inf->pspace == pspace) + return inf; for (inf = inferior_list; inf != NULL; inf = inf->next) { |