possible QTFrame enhancement

[David Taylor]

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.

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
QTFrame-:pc:addr
QTFrame-:tdp:t
QTFrame-:range: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?

Thanks.

David

[Pedro Alves]

Post by David Taylor
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
QTFrame:n
QTFrame:pc:addr
QTFrame:tdp:t
QTFrame:range:start:end
QTFrame:outside:start:end
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".

Post by David Taylor
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
QTFrame-:n

This one doesn't seem to make sense. QTFrame:n means "find frame number N".
How would that be any different?

Post by David Taylor
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

Post by David Taylor
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

[Stan Shebs]

Post by Pedro Alves

Post by David Taylor
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
QTFrame:n
QTFrame:pc:addr
QTFrame:tdp:t
QTFrame:range:start:end
QTFrame:outside:start:end
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".

Post by David Taylor
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
QTFrame-:n

This one doesn't seem to make sense. QTFrame:n means "find frame number N".
How would that be any different?

"N from the last frame" perhaps? Although GDB does get told how many
trace frames have been collected, so it can calculate "N from the end"
itself.

Post by Pedro Alves

Post by David Taylor
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.

I concur. I can't think of many other actual tracepoint users right
now, so your developer gets lots of influence on how it develops
further.

One funky idea that occurs to me, looking at this proposal - QTFrame
packet with an agent expression? The whole theory of QTFrame is to
instruct the target how to find a trace frame, so if you have lots of
trace frames, maybe you'd want to find by content:

tfind collectedvar < 0

Compile expression to bytecode, pass it in packet, let the target agent
iterate over the trace buffer and report first one found. It would be
some weird byecode interpreter hackery I suppose, reading from buffer
instead of live memory, but probably OK speedwise, since everything is
in RAM.

Stan
***@codesourcery.com

[David Taylor]

Post by Stan Shebs

Post by Pedro Alves

Post by David Taylor
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.

Thanks. I agree.

Post by Stan Shebs

Post by Pedro Alves

Post by David Taylor
QTFrame-:n

This one doesn't seem to make sense. QTFrame:n means "find frame number N".
How would that be any different?

I meant to delete that one but slipped up.

Post by Stan Shebs
"N from the last frame" perhaps? Although GDB does get told how many
trace frames have been collected, so it can calculate "N from the end"
itself.

That to me is a reasonable semantic for it. But, it is probably not
needed.

Post by Stan Shebs

Post by Pedro Alves

Post by David Taylor
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.

Assuming gdbserver supports the existing QTFrame subcommands already, I
would expect this to be part of the contribution.

Post by Stan Shebs
I concur. I can't think of many other actual tracepoint users right
now, so your developer gets lots of influence on how it develops
further.

We (EMC) have a fair number of tracepoint users. We have two remote
stub frontends that GDB can talk with. The two stubs share a backend
(breakpoint, tracepoint, single step, expression evaluation engine).

The original stub owes a lot of Cygnus Solutions, though it has been
heavily modified since then. It is over 10 years old and has a number
of non standard extensions. We are rewriting it and trying to use
standard features whenever possible.

Until recently we did not support breakpoints except as incidental to
tracepoints.

Post by Stan Shebs
One funky idea that occurs to me, looking at this proposal - QTFrame
packet with an agent expression? The whole theory of QTFrame is to
instruct the target how to find a trace frame, so if you have lots of
tfind collectedvar < 0

That *WOULD* be useful. Quite useful. I would want some additional
bytecodes / operators, though. Like a way to test whether something was
collected. If, to use your example, you typed:

tfind collectedvar < 0

and collectedvar was only collected at some tracepoints, what should
happen at tracepoints where it was not collected?

If

QTFrame:expr:<expression>

(or something simiilar) existed, then the other QTFrame variants would
effectively just be special cases. I'm not sure how efficient it would
be, but it sure would be powerful.

Post by Stan Shebs
Compile expression to bytecode, pass it in packet, let the target agent
iterate over the trace buffer and report first one found. It would be
some weird byecode interpreter hackery I suppose, reading from buffer
instead of live memory, but probably OK speedwise, since everything is
in RAM.

Sounds like fun. But, it is a separate project and not part of this
proposal.

Which do people prefer --

QTFrame-:<subcommand>
or
QTFrame:-<subcommand>
or
something else?

I have two desires with regards to the remote protocol message --

. I don't want whomever reviews it to say, effectively, ``I won't
approve it unless you change the remote protocol message to be ...''.

I want such issues to be decided before implementation. We plan to
deploy this in our stub and I don't want to have to support two
syntaxes...

If it is rejected based on the quality of the implementation, that it
a totally separate matter. But, I want the user interface and remote
protocol messages decided before implementation starts.

. I want it to be a syntax that if the stub doesn't support it, it can
say so (i.e., reply with an empty message), rather than reply saying
it had trouble parsing the message.

Other than that, I don't much care what the remote protocol message
looks like.

Post by Stan Shebs
Stan

David