This is the mail archive of the
gdb@sourceware.org
mailing list for the GDB project.
Re: possible QTFrame enhancement
- From: Pedro Alves <palves at redhat dot com>
- To: David Taylor <dtaylor at usendtaylorx2l dot lss dot emc dot com>, "gdb at sourceware dot org" <gdb at sourceware dot org>
- Date: Thu, 16 Oct 2014 22:15:26 +0100
- Subject: Re: possible QTFrame enhancement
- Authentication-results: sourceware.org; auth=none
- References: <4250 dot 1411074396 at usendtaylorx2l> <13378 dot 1413479010 at usendtaylorx2l>
On 10/16/2014 06:03 PM, David Taylor wrote:
> In mid September I asked about a possible QTFrame / tfind enhancement.
> That message generated zero responses.
>
> I'm hoping to get back in a day or two to our effort of adding the
> setting of memory and registers at tracepoints. (It's more than half
> done; but, before I finished I got yanked onto another project.) I
> won't be working on implementing these proposed QTFrame / tframe
> enhancements until that (and possibly some other stuff) is done.
>
> For the remote protocol there currently several variants of the QTFrame
> message:
>
> QTFrame:n
> QTFrame:pc:addr
> QTFrame:tdp:t
> QTFrame:range:start:end
> QTFrame:outside:start:end
>
> And variants of the tfind command:
>
> 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.
That makes a lot of sense. Kind of a glaring omission, even.
In a way, "tfind" is like "si/step/etc", and "tfind -r" would
be like "reverse-si/step/etc".
>
> Other than the first QTFrame variant above -- which does no searching --
> all of the above QTFrame variants search *FORWARDS* from the current
> tracepoint frame.
>
> I would like to propose that tfind be modified from
>
> tfind <existing-subcommand> <existing-arguments>
> to
>
> tfind <existing-subcommand> [ -r | --reverse] <existing-arguments>
>
> and that the QTFrame remote protocol message have an optional `-' before
> the first `:' to indicate reverse:
>
> QTFrame-:n
This one doesn't seem to make sense. QTFrame:n means "find frame number N".
How would that be any different?
> QTFrame-:pc:addr
> QTFrame-:tdp:t
> QTFrame-:range:start:end
> QTFrame-:outside:start:end
I think it might make sense to put the '-' on the "how" part
then, that is, after the ':', thus we'd have:
QTFrame:n
QTFrame:pc:addr
QTFrame:-pc:addr
QTFrame:tdp:t
QTFrame:-tdp:t
QTFrame:range:start:end
QTFrame:-range:start:end
QTFrame:outside:start:end
QTFrame:-outside:start:end
>
> And for qSupported I propose:
>
> QTFrameReverse+
> QTFrameReverse-
>
> to indicate whether it is supported or not.
>
> Does this proposal seem reasonable to people? Would an implementation
> of this stand a resonable chance of being accepted back?
Yes. If it comes along with a reference implementation in
gdbserver, even better.
Thanks,
Pedro Alves