Re: -var-update @

[Vladimir Prus <ghost@cs.msu.su>]

Vladimir Prus wrote:

> On Friday 04 April 2008 00:04:03 Nick Roberts wrote:
>> 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.
> 
> Well, if your patch fixes the issue that *you* saw, then it's already an improvement,
> and we better get it into the tree as soon as possible.

Nick,
for avoidance of doubt -- are you planning to finish this patch in near future?
If not, I'll pick it up.

- Volodya