trace state variables -- what should be traced?

trace state variables -- what should be traced?

[David Taylor]

For trace state variables, what should be traced?

If I reference a trace state variable in a tracepoint action, its value
will be collected and placed into the trace frame.

If it's not a trace state variable, but rather just an 'ordinary'
variable, then there is, currently, no ambiguity.  But, for trace state
variables, it can be set with an aop_setv operation.  Which value should
be recorded?

The old value?  Or the new value?

Currently the new value is always recorded and sometimes the old value
is recorded as well.

Since the old value, when it is recorded, is always recorded prior to
recording the new value, the new value overwrites the old value.

The manual doesn't say what happens, but I would argue that the old
value should always be recorded and never the new value.

Thoughts?

Knowing the collection expression and the values of everything in it
allows me to compute the new value.  But, I cannot similarly compute the
old value.  Once it is overwritten it is lost forever.

There are 4 places where aop_tracev is generated, all 4 are in
gdb/ax-gdb.c, function gen_expr.

case BINOP_ASSIGN:

	      ax_tsv (ax, aop_setv, tsv->number);
	      if (ax->tracing)
		ax_tsv (ax, aop_tracev, tsv->number);

case BINOP_ASSIGN_MODIFY:

	      ax_tsv (ax, aop_getv, tsv->number);
	      if (ax->tracing)
		ax_tsv (ax, aop_tracev, tsv->number);

and then a little bit later in that same case:

	      ax_tsv (ax, aop_setv, tsv->number);
	      if (ax->tracing)
		ax_tsv (ax, aop_tracev, tsv->number);

case OP_INTERNALVAR:

	    ax_tsv (ax, aop_getv, tsv->number);
	    if (ax->tracing)
	      ax_tsv (ax, aop_tracev, tsv->number);

If you agree, then the first (BINOP_ASSIGN) should have the setv moved
after the tracev to become:

	      if (ax->tracing)
		ax_tsv (ax, aop_tracev, tsv->number);
	      ax_tsv (ax, aop_setv, tsv->number);

and the third (second one in BINOP_ASSIGN_MODIFY) should have the 

	      if (ax->tracing)
		ax_tsv (ax, aop_tracev, tsv->number);

lines deleted.

Comments?

David

Re: trace state variables -- what should be traced?

[Yao Qi]

David Taylor <dtaylor@emc.com> writes:

> variables, it can be set with an aop_setv operation.  Which value should
> be recorded?
>
> The old value?  Or the new value?

I prefer both.

>
> Currently the new value is always recorded and sometimes the old value
> is recorded as well.

Do you have an example that old value is *not* recorded?

>
> Since the old value, when it is recorded, is always recorded prior to
> recording the new value, the new value overwrites the old value.

The old value and the new value are recorded in the different 'V' blocks
of the traceframe, so the new value shouldn't overwrite the old value.
There was a bug in GDB that it reads the first matched tsv, so the old value
of this tsv may be read, but this bug was fixed by reading last matched
tsv <https://sourceware.org/ml/gdb-patches/2013-03/msg00255.html>

-- 
Yao (齐尧)

Re: trace state variables -- what should be traced?

[David Taylor]

Yao Qi <yao@codesourcery.com> wrote:

> David Taylor <dtaylor@emc.com> writes:
> 
> > variables, it can be set with an aop_setv operation.  Which value should
> > be recorded?
> >
> > The old value?  Or the new value?
> 
> I prefer both.

But, only one is accessible.  Even if the others are stored. only one
will be seen by GDB.  The target stub or gdbserver will search its data
base of what was stored and if multiple are present, it will pick one --
probably either the first or the last; the others will be ignored.

Whether multiple values get stored or later ones overwrite or get
dropped is a target stub implmentation detail that GDB has no control
over.  Further, other than the case of gdbserver, even if multiple get
stored, GDB has no control over which one gets returned.

The remote protocol does not currently have a way of asking how many
values got stored nor for asking for a specific one of the values.

> >
> > Currently the new value is always recorded and sometimes the old value
> > is recorded as well.
> 
> Do you have an example that old value is *not* recorded?

Sure.  Typing:

    tvariable $tvar=100
    maint agent $tvar = 78

produces:

    Scope: 0x500a290
    Reg mask: 00
      0  const8 78
      2  setv 1
      5  tracev 1
      8  pop
      9  end

in GDB 7.8.

> > Since the old value, when it is recorded, is always recorded prior to
> > recording the new value, the new value overwrites the old value.
> 
> The old value and the new value are recorded in the different 'V' blocks
> of the traceframe, so the new value shouldn't overwrite the old value.
> There was a bug in GDB that it reads the first matched tsv, so the old value
> of this tsv may be read, but this bug was fixed by reading last matched
> tsv <https://sourceware.org/ml/gdb-patches/2013-03/msg00255.html>

This is gdbserver specific.  Some stubs will behave differently.  The
GDB manual does not say what should be returned if multiple values are
present.  Nor what should happen if the stub is requested to store the
value at the same address multiple times at the same tracepoint hit.

> -- 
> Yao (齐尧)

David

Re: trace state variables -- what should be traced?

[Yao Qi]

David Taylor <dtaylor@emc.com> writes:

> But, only one is accessible.  Even if the others are stored. only one
> will be seen by GDB.  The target stub or gdbserver will search its data
> base of what was stored and if multiple are present, it will pick one --
> probably either the first or the last; the others will be ignored.
>

That is correct.

> Whether multiple values get stored or later ones overwrite or get
> dropped is a target stub implmentation detail that GDB has no control

This is not target stub implementation detail to me.  See tracev in
https://sourceware.org/gdb/current/onlinedocs/gdb/Bytecode-Descriptions.html

tracev (0x2e) n: ⇒ a
Record the value of trace state variable number n in the trace buffer.

target stub shouldn't drop the value nor overwrite the value, because of
the verb "Record" here.  IOW, once target stub sees tracev, it has to
save or record the value of TSV somewhere.  This is in the stub side.

> over.  Further, other than the case of gdbserver, even if multiple get
> stored, GDB has no control over which one gets returned.

GDB doesn't have to control over which one gets returned.  GDB only gets
the 'correct' value from the target stub.  See test case
gdb.trace/tsv.exp,

 - tvariable $tvar5 = 15
 - Set action to collect $tvar5 += 1
 - Check the value of $tvar5 (16) after the tracepoint is hit

GDB doesn't know how many $tvar5 values are stored in one trace frame
in stub side, but stub has to return the correct value 16.

>
> The remote protocol does not currently have a way of asking how many
> values got stored nor for asking for a specific one of the values.

remote protocol isn't aware of how tsv values are stored in a trace
frame either.

>> > Since the old value, when it is recorded, is always recorded prior to
>> > recording the new value, the new value overwrites the old value.
>> 
>> The old value and the new value are recorded in the different 'V' blocks
>> of the traceframe, so the new value shouldn't overwrite the old value.
>> There was a bug in GDB that it reads the first matched tsv, so the old value
>> of this tsv may be read, but this bug was fixed by reading last matched
>> tsv <https://sourceware.org/ml/gdb-patches/2013-03/msg00255.html>
>
> This is gdbserver specific.  Some stubs will behave differently.  The
> GDB manual does not say what should be returned if multiple values are
> present.  Nor what should happen if the stub is requested to store the
> value at the same address multiple times at the same tracepoint hit.

The target stub has to provide the 'correct' (or latest) value of TSV,
but it is nothing to do with how TSV values are stored.

In short, how tsv values are stored in trace frame is the implementation
details of different target stubs, but target stub has to provide the
latest value of tsv when GDB sends requests to it.

-- 
Yao (齐尧)