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

[David Taylor <dtaylor at emc dot com>]

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