Re: [PATCH, gdbserver] Fix a bug on uploading tracepoint actions.

[Pedro Alves <palves at redhat dot com>]

On 03/07/2013 08:33 AM, Yao Qi wrote:

> OTH, the uploaded actions will/may be used in
> tracepoint.c:find_matching_tracepoint_location
> 
>       if (b->type == utp->type
> 	  && t->step_count == utp->step
> 	  && t->pass_count == utp->pass
> 	  && cond_string_is_same (t->base.cond_string, utp->cond_string)
> 	  /* FIXME also test actions.  */
> 
> Do we really need testing uploaded actions here?  

Hmm.  I can see a newer GDB compiling the agent expressions
differently from what the original GDB had downloaded.  Or even
say the tracepoint was created in a shared library that isn't loaded
when you reconnected.  I don't think that should cause the tracepoint
to not match.  A warning would be somewhat useful perhaps.

> Is it a
> good (or bad) idea to stop uploading actions in GDBserver and writing
> actions into tfile?  This change shouldn't bring any compatibility
> issues.  What do you think?

Hmm.

In some use cases, you may want to pass the tfile (or something post
processed from it) directly to the target without GDB involvement.
I think I recall some plans around this for some CS project,
though I don't recall details anymore.  So having the already generated
agent expression actions in the tfile seems useful for that case.

The way GDB compiles the actions may change, as newer GDBs
may end up compiling more efficient agent expressions, etc.  Or even
generating the exact same actions may be difficult, as you may
need to setup the program in a certain way in order to have it
load the code you want to trace.

Uploading the generated actions and putting them in the tfile seems
useful as a guarantee that the tfile has the exact tracepoint
definitions the target had, useful for posterity and debugging
the trace data collection itself, after the fact.
Say you set a trace session in
the field, let it run for a week, and when done, it gets uploaded with GDB
into a tfile.  Later on, in the office, you're looking at the data, and
it's not really making sense (collected wrong things), or it's more or
less data than you thought would be, etc., etc.  Looking at the generated
actions may be a good debugging tool, to figure out exactly what agent
expressions the tracepoints ran.

Maybe Stan can shed some further light on the original plan and its
requirements.

> 
> gdb/gdbserver:
> 
> 2013-03-07  Yao Qi  <yao@codesourcery.com>
> 
> 	* tracepoint.c (cur_action, cur_step_action): Make them unsigned.
> 	(cmd_qtfp): Initialize cur_action and cur_step_action 0 instead
> 	of -1.
> 	(cmd_qtsp): Adjust condition.  Do post increment.
> 	Set cur_action and cur_step_action back to 0.

This is OK.  Thanks.

-- 
Pedro Alves