Re: possible QTFrame enhancement

Stan Shebs <[email protected]> wrote:

> On 10/16/14, 2:15 PM, Pedro Alves wrote:
> > On 10/16/2014 06:03 PM, David Taylor wrote:

> >> 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.

> >>     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.

> "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.

> >> 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.

> 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.

> 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

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.

> 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.

> Stan
> [email protected]

David