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

[Yao Qi <yao at codesourcery dot com>]

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 (éå)