]> git.ipfire.org Git - thirdparty/binutils-gdb.git/commit
Reduce Hg packet (select remote general thread) bouncing
authorPedro Alves <palves@redhat.com>
Thu, 2 Oct 2014 08:55:38 +0000 (09:55 +0100)
committerPedro Alves <palves@redhat.com>
Thu, 2 Oct 2014 08:55:38 +0000 (09:55 +0100)
commit32990adaadc1b119700cd0dfd2dd8849114e0135
tree2d9c197dc5bd9234d2b98078e19540696dadc241
parentdac3fe877844e76de9cf102151837998aa1d2a8f
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.
gdb/ChangeLog
gdb/gdbthread.h
gdb/inferior.c
gdb/inferior.h
gdb/progspace.c
gdb/progspace.h
gdb/thread.c