From: David Taylor <dtaylor@emc.com>
To: Yao Qi <yao@codesourcery.com>
Cc: "gdb\@sourceware.org" <gdb@sourceware.org>
Subject: Re: trace state variables -- what should be traced?
Date: Mon, 15 Sep 2014 14:19:00 -0000 [thread overview]
Message-ID: <28917.1410790743@usendtaylorx2l> (raw)
In-Reply-To: <87iokp4joy.fsf@codesourcery.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
next prev parent reply other threads:[~2014-09-15 14:19 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-09-12 19:45 David Taylor
2014-09-15 4:04 ` Yao Qi
2014-09-15 14:19 ` David Taylor [this message]
2014-09-18 13:38 ` Yao Qi
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=28917.1410790743@usendtaylorx2l \
--to=dtaylor@emc.com \
--cc=gdb@sourceware.org \
--cc=yao@codesourcery.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox