possible QTFrame enhancement

possible QTFrame enhancement

[David Taylor]

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

Re: 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

Re: possible QTFrame enhancement

[Pedro Alves]

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

Re: possible QTFrame enhancement

[Stan Shebs]

On 10/16/14, 2:15 PM, Pedro Alves wrote:
> 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?

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

>> 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
stan@codesourcery.com

Re: possible QTFrame enhancement

[David Taylor]

Stan Shebs <stanshebs@earthlink.net> 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
> stan@codesourcery.com

David

Re: possible QTFrame enhancement

[Doug Evans]

On Thu, Oct 16, 2014 at 4:23 PM, Stan Shebs <stanshebs@earthlink.net> wrote:
> [...]
> 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.

While we're on the subject, now's a good time to mention something
that is on my plate.

Tracepoints suck at collecting c++ data (e.g., what a pretty-printer
would need).
The canonical solution that occurs to me is to do it in python (allow
one to specify what to collect for particular types).
The compiler knows how c++ classes are laid out, but there is still
some intelligence that goes into knowing or optimizing what to
collect.
Plus one would want (I think) the code to live with the pretty-printer
- easier to maintain.

These are just ideas for discussion.
I haven't gone too far down this path.

Re: possible QTFrame enhancement

[Stan Shebs]

On 10/29/14, 12:01 PM, Doug Evans wrote:
> On Thu, Oct 16, 2014 at 4:23 PM, Stan Shebs <stanshebs@earthlink.net> wrote:
>> [...]
>> 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.
> 
> While we're on the subject, now's a good time to mention something
> that is on my plate.
> 
> Tracepoints suck at collecting c++ data (e.g., what a pretty-printer
> would need).
> The canonical solution that occurs to me is to do it in python (allow
> one to specify what to collect for particular types).
> The compiler knows how c++ classes are laid out, but there is still
> some intelligence that goes into knowing or optimizing what to
> collect.
> Plus one would want (I think) the code to live with the pretty-printer
> - easier to maintain.
> 
> These are just ideas for discussion.
> I haven't gone too far down this path.
> 

Certainly a stimulating direction for thought!

Bytecode compilation is basically a simple-minded expression walker, so
it's not too much of a stretch to imagine a modified pretty printer that
emits bytecodes to collect what it thinks it will need.

It starts to break down a little when the pretty printer has
conditionals, because the bytecode compiler has to take both paths and
emit bytecodes for each.  But it's worthwhile if the printer only needs
4 words of a 100-word object - that's a lot of space you're saving per
trace frame.

A downside is that display is limited to what the pretty printer asks
for, so if you have a suspicious situation where a pointer field looks
overwritten by the chars of a string, but the data fields right after
the pointer were not collected because the pretty printer doesn't
normally display them, the user is out of luck in seeing the rest of the
overwrite.  So in general we tend to want to over-collect.

It would be an interesting and not-too-hard trick to add a user control
to broaden the collection bytecodes - tweak every block save to include,
say, the 10 bytes above and below the specified block.

Stan
stan@codesourcery.com

filtering traceframes (was: Re: possible QTFrame enhancement)

[David Taylor]

I've been thinking some more about filtering traceframes.

You can think of the variations of tfind command as basically being
filtering variants.  Show me the next / previous trace frame

. at a particular pc (tfind pc)
. from a particular tracepoint (tfind tp)
. within some pc range (tfind range)
. outside some pc range (tfind outside)

And we have users that do filtering, on the desktop, based on other
criteria.

I would like to move much of this filtering to the stub.

If you have a small number of trace frames or if most of your trace
frame 'match' the filter, then it probably doesn't matter where the
filtering is done.  But, if you have a large number of frame (e.g., over
100,000) and a small fraction (say, 1/1000) match the filter, then
it can make a big difference to where the filtering occurs.

At first I was thinking just support

    tfind expr <expression>

but on reflection, I don't think that that is enough.  You want to be
able to say ``give me the next / previous trace frame that is

. at a particular pc (tfind pc)
. from a particular tracepoint (tfind tp)
. within some pc range (tfind range)
. outside some pc range (tfind outside)

*AND* matches this expression.

So, now I'm thinking, for user interface:

tfind <tfind subcommand>
    [-r | --reverse]
    [-e <expr> | --expr <expr>]
    <subcommand args>

where [-e <expr> | --expr <expr>] would only be defined for those tfind
subcommands where it made sense.

Using the existing QTFrame remote protocol messages but tacking on

    :X<byte count>,<hex encoded expression>

at the end.  And letting GDB know that the stub supports it by adding
TraceFrameExprs followed by '+' or '-' to the qSupported response.
(Default being either not supported or probe for it (assuming there's a
reasonable way to probe for it.))

I haven't begun to think about implementation details (and I have other
things on my plate, so I'm certain to not get to it this quarter even if
I get management approval), but I would like feedback and thoughts.

David
dtaylor at emc dot com

Re: filtering traceframes (was: Re: possible QTFrame enhancement)

[Doug Evans]

On Fri, Feb 13, 2015 at 11:47 AM, David Taylor <dtaylor@emc.com> wrote:
> I've been thinking some more about filtering traceframes.
>
> You can think of the variations of tfind command as basically being
> filtering variants.  Show me the next / previous trace frame
>
> . at a particular pc (tfind pc)
> . from a particular tracepoint (tfind tp)
> . within some pc range (tfind range)
> . outside some pc range (tfind outside)
>
> And we have users that do filtering, on the desktop, based on other
> criteria.
>
> I would like to move much of this filtering to the stub.
>
> If you have a small number of trace frames or if most of your trace
> frame 'match' the filter, then it probably doesn't matter where the
> filtering is done.  But, if you have a large number of frame (e.g., over
> 100,000) and a small fraction (say, 1/1000) match the filter, then
> it can make a big difference to where the filtering occurs.
>
> At first I was thinking just support
>
>     tfind expr <expression>
>
> but on reflection, I don't think that that is enough.  You want to be
> able to say ``give me the next / previous trace frame that is
>
> . at a particular pc (tfind pc)
> . from a particular tracepoint (tfind tp)
> . within some pc range (tfind range)
> . outside some pc range (tfind outside)
>
> *AND* matches this expression.
>
> So, now I'm thinking, for user interface:
>
> tfind <tfind subcommand>
>     [-r | --reverse]
>     [-e <expr> | --expr <expr>]
>     <subcommand args>
>
> where [-e <expr> | --expr <expr>] would only be defined for those tfind
> subcommands where it made sense.
>
> Using the existing QTFrame remote protocol messages but tacking on
>
>     :X<byte count>,<hex encoded expression>
>
> at the end.  And letting GDB know that the stub supports it by adding
> TraceFrameExprs followed by '+' or '-' to the qSupported response.
> (Default being either not supported or probe for it (assuming there's a
> reasonable way to probe for it.))
>
> I haven't begun to think about implementation details (and I have other
> things on my plate, so I'm certain to not get to it this quarter even if
> I get management approval), but I would like feedback and thoughts.
>
> David
> dtaylor at emc dot com

Improving gdb's ability to scale is certainly a goal we want to pursue
so I'm guessing there's no disagreement on wanting something
along these lines.

Another way to go would be to provide a general tfind and make
"tfind pc", etc. special cases of it.

E.g., tfind -p <pc> -e <expr>

then "tfind pc <pc>" == "tfind -p <pc>"

IOW, it's odd to treat expr and pc differently in the syntax.
I'd like to avoid that.

Given how similar "tfind pc ..." and "tfind -p ..." are,
another way to go is:

tfind pc <pc> expr <some_expr>
tfind expr <some_expr> pc <pc>

IOW, for subcommands that specify a condition, allow multiple "subcommands".

Another way to go, though I don't know if this would work as written here,
would be to provide ways of specifying "pc <pc>" and
"range|outside <addr1>,<addr2>" in an expression, and thus have
something like:

tfind expr ($pc == <pc>) && $outside(addr1,addr2) && some_expr

Maybe this would be better:

tfind expr $is_pc(pc) && some_expr
tfind expr $pc_in_range(addr1,addr2) && some_expr

[or whatever spelling for is_pc,pc_in_range, etc. works]

IOW, allow specifying everything in the expression.

One needn't have a replacement for "outside" because it's just:

tfind expr !$pc_in_range(addr1,addr2)

One could even remove "range" and have $is_pc (or whatever)
take one or two arguments.

Anyways, long story short, I don't have a strong preference
other than if we're going to extend things, let's (try to) extend
it in a general direction instead of, e.g., adding -e/--expr to
tfind pc|outside|range.