tracepoints -- DWARF and tstart

tracepoints -- DWARF and tstart

[David Taylor]

When doing a trace experiment, GDB waits until you type 'tstart' to
generate the agent byte code expressions that it will send to the GDB
stub running on the remote target.

This might be okay if the conversion never produced an error.

Alas, it *CAN* produce an error *AND* GDB is rather stingy with the
information that it shares with the user when this happens.

Imagine a trace experiment where you have defined half a dozen
tracepoints, each with some collection actions.  You type

    tstart

and GDB responds with something like

    DWARF operator DW_OP_GNU_implicit_pointer cannot be translated to an
    agent expression.

and the trace experiment is *NOT* started.

You've got a problem to debug.  You are trying to run a trace experiment
to collect information to debug the problem.  And GDB is being rather,
shall we say, unhelpful.

Ideal would be to get the errors, if any, when you type the <return>
ending the particular 'collect' action.

Second best would be to get them, along with which collect was the
problem, when you type the 'end' ending the set of actions associated
with the tracepoint.

Getting it with 'tstart', while not ideal, would be a lot better if it
told you *WHICH* tracepoint and *WHICH* collect action are the cause of
the problem.

And, if they are going to occur at 'tstart' time, a warning would be
nicer.  That is, allow the experiment to run without that particular
variable / expression.  If the expression is '$locals', then warning
about whichever variable is the problem and collecting the rest would
be nice.

My current thinking is to do the last option above (it seems the easiest
/ quickest) and think about what would be required to give the error
earlier.

Thoughts?

RE: tracepoints -- DWARF and tstart

[Marc Khouzam]

> From: gdb-owner@sourceware.org [gdb-owner@sourceware.org] on behalf of David Taylor [dtaylor@emc.com]
> Sent: May 16, 2016 3:24 PM
> To: gdb@sourceware.org
> Subject: tracepoints -- DWARF and tstart
> 
> When doing a trace experiment, GDB waits until you type 'tstart' to
> generate the agent byte code expressions that it will send to the GDB
> stub running on the remote target.
> 
> This might be okay if the conversion never produced an error.
> 
> Alas, it *CAN* produce an error *AND* GDB is rather stingy with the
> information that it shares with the user when this happens.
> 
> Imagine a trace experiment where you have defined half a dozen
> tracepoints, each with some collection actions.  You type
> 
>     tstart
> 
> and GDB responds with something like
> 
>     DWARF operator DW_OP_GNU_implicit_pointer cannot be translated to an
>     agent expression.
> 
> and the trace experiment is *NOT* started.
> 
> You've got a problem to debug.  You are trying to run a trace experiment
> to collect information to debug the problem.  And GDB is being rather,
> shall we say, unhelpful.
> 
> Ideal would be to get the errors, if any, when you type the <return>
> ending the particular 'collect' action.
> 
> Second best would be to get them, along with which collect was the
> problem, when you type the 'end' ending the set of actions associated
> with the tracepoint.
> 
> Getting it with 'tstart', while not ideal, would be a lot better if it
> told you *WHICH* tracepoint and *WHICH* collect action are the cause of
> the problem.
> 
> And, if they are going to occur at 'tstart' time, a warning would be
> nicer.  That is, allow the experiment to run without that particular
> variable / expression.  If the expression is '$locals', then warning
> about whichever variable is the problem and collecting the rest would
> be nice.
> 
> My current thinking is to do the last option above (it seems the easiest
> / quickest) and think about what would be required to give the error
> earlier.
> 
> Thoughts?

I completely agree that the current error reporting for tracepoints
gives a very poor user experience.

Besides the lack of clarity on how to fix the error, waiting for tstart is
problematic.  When the user types tstart, it is time to start tracing. The
user may have waited until a particular time when the error can easily
be reproduced to trigger the tracing. When tstart fails, it delays the
start of the tracing experiment and could cause the user to miss the
time window.

One can imagine a real world scenario where a designer sets up all
the tracepoints at a customer site and leaves the enabling of
tracing (tstart) to a less technical person once night time comes and
the customer's computers can be monitored freely. If the tstart fails,
then the developer is not on site anymore and fixing it may have to
wait until the next day.

It would be much more user friendly to know the tracepoints have an
error as soon as they are created. IIRC, this is not trivial since
tracepoints are not actually pushed to the target until tstart. But I hope
there may be some tricks to work around that.

Thanks David for bringing this up. I think it is an important shortcoming
of the current tracepoint support.

Marc