This is the mail archive of the
mailing list for the GDB project.
Re: -var-update @
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.
>> 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.
for avoidance of doubt -- are you planning to finish this patch in near future?
If not, I'll pick it up.