Mirror of the gdb mailing list
 help / color / mirror / Atom feed
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


  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