Mirror of the gdb-patches mailing list
 help / color / mirror / Atom feed
From: Nick Roberts <nickrob@snap.net.nz>
To: Vladimir Prus <ghost@cs.msu.su>
Cc: gdb-patches@sources.redhat.com
Subject: Re: MI testsuite failures
Date: Mon, 08 Jan 2007 08:15:00 -0000	[thread overview]
Message-ID: <17825.64924.680523.195443@kahikatea.snap.net.nz> (raw)
In-Reply-To: <E1H3pBF-0002gK-AV@zigzag.lvk.cs.msu.su>

 > >   FAIL: gdb.mi/mi-var-cmd.exp: assign same value to func (update)
 > > 
 > > This is more subtle and is caused by having two variable objects for
 > > one variable, var1 and var2 say.  Then if they have a common value 10
 > > say and you do:
 > > 
 > > -var-assign var1 11
 > > -var-assign var2 12
 > > 
 > > var->updated is set to 1 for each and they are both reported as changed
 > > with -var-update.
 > > 
 > > However doing -var-update again gives var1 in the chagelist because the
 > > real value is 12 but var->print_value is "11".
 > 
 > That's because -var-assign should update var->print_value.

"-var-assign var2 12" will update var->print_value for var2 but not var1.  If
you can see a way to do update both please show me.

 > > I think this is a bug in -var-assign; it should set the variable value
 > > but not interfere with the variable object.  Note that generally if you
 > > have two variable objects for one value and set the value of one with
 > > -var-assign, one will be reported as changed because var->updated is 1,
 > > and the other because the value has changed.  I think the value held
 > > by the variable object shouldn't change until -var-update is issued,
 > > just as is the case if the real value changes during execution.  This is
 > > a patch to do that.
 > 
 > I don't think that if you assign a value to varobj and then
 > -var-evaluate-expression returns something else than the value you've
 > assigned, it would be rather confusing interface.

I recall that when I submitted my first patches (start of 2003?) Daniel J was
confused by the fact that -var-evaluate-expression didn't always return the
current variable value, and Jim Ingham explained that variable objects were
designed to work like that.  It only appears confusing because you're used to
the current behaviour.

-- 
Nick                                           http://www.inet.net.nz/~nickrob


  reply	other threads:[~2007-01-08  8:15 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-01-07 23:34 Nick Roberts
2007-01-08  5:53 ` MI testsuite failures [PATCH] Nick Roberts
2007-01-08 17:11   ` Daniel Jacobowitz
2007-01-08 22:33     ` Nick Roberts
2007-01-08 22:45       ` Daniel Jacobowitz
2007-01-08 23:27         ` Nick Roberts
2007-01-09 14:26           ` Daniel Jacobowitz
2007-01-09 22:18             ` Nick Roberts
2007-01-09 22:50               ` Daniel Jacobowitz
2007-01-10  7:09                 ` Nick Roberts
2007-01-10 20:23                   ` Daniel Jacobowitz
2007-01-08  7:44 ` MI testsuite failures Vladimir Prus
2007-01-08  8:15   ` Nick Roberts [this message]
2007-01-08  9:40     ` Vladimir Prus

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=17825.64924.680523.195443@kahikatea.snap.net.nz \
    --to=nickrob@snap.net.nz \
    --cc=gdb-patches@sources.redhat.com \
    --cc=ghost@cs.msu.su \
    /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