Re: Variable objects laziness

[Vladimir Prus <vladimir@codesourcery.com>]

Daniel Jacobowitz wrote:

> On Fri, Nov 17, 2006 at 01:44:53PM +0300, Vladimir Prus wrote:
>> On Friday 17 November 2006 13:40, Mark Kettenis wrote:
>> > >  Daniel Jacobowitz wrote:
>> > > > Sorry, you're right!
>> > > >
>> > > > When you're ready, please repost.  Might want to finish talking
>> > > > with Nick first.
>> >
>> > As Nick indicated, I'm not sure whether the removal of my_value_equal
>> > is ok. The whole point of my_value_equal is to check equality of values
>> > without error()ing out if we can't read a value.  Your replacement code
>> > doesn't seem to take that possibility into account.
>> 
>> Are you sure? The code has exactly one place where value is fetched, and
>> it does that by the call to gdb_value_fetch_lazy -- that calls
>> value_fetch_lazy in a try block. Any errors will be caught and cause the
>> value to be set to NULL.
> 
> I think this is the key bit - my_value_equal called value_fetch_lazy,
> the new code calls gdb_value_fetch_lazy.
> 
> Vlad, I noticed that the old code used coerce_array and the new one
> doesn't.  Is that a problem?

This should not be a problem on -var-update path, because we never try
to compare values of array types, since for them type_changeable returns
false.

However, it looks to be a problem on -var-assign path. Given:

   int b[] = {1,2,3};
   int *a  = b;

if we create varobj for 'a' and assign it the value of 'b', we should not
mark this variable as changed.

I'll double-check this (and other coercions that coerce_array silently does)
and add new test cases as needed.

Thanks,
Volodya