For remotes which do not support btrace at all, we can save several
round trips for each thread. This is especially significant when your
remote is a kernel with 100s or 1000s of threads and latency is
intercontinental.
Previously, with target, remote, and infrun debugging enabled, one
might see:
Sending packet: $Hg18aee#43...Ack
Packet received: OK
Sending packet: $Hg186f7#eb...Ack
Packet received: OK
remote:target_xfer_partial (24, , 0x805454000, 0x0, 0x0, 4096) = -1, 0
repeated for all non-exited threads.
Afterwards, if the remote does not specify 'qXfer:btrace-conf:read+'
in qSupported stub features, these unnecessary thread switches are
avoided.
gdb/ChangeLog:
* remote.c (remote_target::remote_btrace_maybe_reopen): Avoid
unnecessary thread walk if remote doesn't support the packet.
+2019-08-20 Conrad Meyer <cem@FreeBSD.org>
+
+ * remote.c (remote_target::remote_btrace_maybe_reopen): Avoid
+ unnecessary thread walk if remote doesn't support the packet.
+
2019-08-19 Tom Tromey <tromey@adacore.com>
* python/py-value.c (value_has_field): Fix indentation.
int warned = 0;
#endif
+ /* Don't bother walking the entirety of the remote thread list when
+ we know the feature isn't supported by the remote. */
+ if (packet_support (PACKET_qXfer_btrace_conf) != PACKET_ENABLE)
+ return;
+
scoped_restore_current_thread restore_thread;
for (thread_info *tp : all_non_exited_threads ())