Re: -var-update @

[Nick Roberts <nickrob@snap.net.nz>]

Vladimir Prus writes:
 > On Sunday 30 March 2008 07:54:08 Nick Roberts wrote:
 > >  > So, we still don't know why the current code does not work? I think
 > >  > we still get to figure out, to make sure that whatever bug there is
 > >  > does not affect other cases.
 > > 
 > > My patch didn't do the right thing (it always marked a floating variable
 > > object as changed) but it's along the right lines.  How about this one?
 > 
 > This patch seem to go in the right direction. I'm somewhat surprised that
 > evaluating previous expression gets bogus value, as opposed to getting value
 > in the frame where varobj was originally created. Any ideas why is that?

I've not tried to understand _exactly_ what value was being retrieved, but
basically var->root->exp was obtained once from gdb_parse_exp_1 in
varobj_create and this has symbol information in var->root->exp->elts[2].
Previously this would be the symbol information for the variable in the frame
for which the variable object was created.  At the same time var->value was
being updated relative to the selected frame, which gave an incorrect address
value in value->address.  I guess a variable's numeric value on the stack is
computed using both the frame address and an address in the symbol table and
these were inconsistent.

	  /* Update expression to new frame.  */
	  tmp_exp = var->root->exp;
	  var->root->exp = tmp_var->root->exp;
	  tmp_var->root->exp = tmp_exp;

Moving var->root->exp into tmp_var->root->exp just ensures that this memory
gets freed when tmp_var is deleted:

	  varobj_delete (tmp_var, NULL, 0);

 > Do you think you can write some test to go along this patch?

We need some tests and documentation at some stage before the next release
but perhaps Bogdan can confirm that this patch works for him first.

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