tracepoints -- DWARF and tstart

[David Taylor <dtaylor at emc dot com>]

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?