This is the mail archive of the
gdb@sourceware.org
mailing list for the GDB project.
possible QTFrame enhancement
- From: David Taylor <dtaylor at emc dot com>
- To: "gdb at sourceware dot org" <gdb at sourceware dot org>
- Date: Thu, 18 Sep 2014 17:06:36 -0400
- Subject: possible QTFrame enhancement
- Authentication-results: sourceware.org; auth=none
For the remote protocol QTFrame message there are everal variants:
QTFrame:n
select the n'th tracepoint frame from the buffer
QTFrame:pc:addr
select the first tracepoint frame *AFTER* the currently seelctd
frame whose PC is addr.
QTFrame:tdp:t
select the first tracepoint frame *AFTER* the currently selected
tracepoint frame that is a hit of tracepoint t.
QTFrame:range:start:end
select the first tracepoint frame *AFTER* the currently selected
fraome whose PC is between start and end
QTFrame:outside:start:end
select the first tracepoint frame *AFTER* the currently selected
frame whose PC is outside the range of addresses.
Which are used by the tfind command and its subcommands:
tfind end
tfind line
tfind none
tfind outside
tfind pc
tfind range
tfind start
tfind tracepoint
We (EMC) have a developer who runs trace experiments that generate
*LOTS* of tracepoint frames -- possibly 100,000 or more! He then likes
to find an anomaly and search *BACKWARDS* to find where things first
started going bad.
Other than the first QTFrame variant above -- which does no searching --
all of the above QTFrame variants search *FORWARDS* from the current
tracepoint frame.
If there was support for searching backwards, what form should it take?
. what should the QTFrame message(s) be?
. what should the tfind commands be?
. should there be a 'token' returned by qSupported to indicate support
for the new messages? And if so, what 'token'? Or should GDB figure it
out by sending one of the messages and trusting that it will get an
error if it is unsupported?
David