This is the mail archive of the
gdb@sourceware.org
mailing list for the GDB project.
tracepoints -- DWARF and tstart
- From: David Taylor <dtaylor at emc dot com>
- To: gdb at sourceware dot org
- Date: Mon, 16 May 2016 15:24:11 -0400
- Subject: tracepoints -- DWARF and tstart
- Authentication-results: sourceware.org; auth=none
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?