Re: Patch for gdb/mi problem 702

[Andrew Cagney <ac131313@redhat.com>]

> On Thu, 3 Oct 2002, J. Johnston wrote:
> 
> 
>> The following fixes a problem with -var-assign whereby an assignment
>> of a new value is not seen by a subsequent -var-update.  The
>> underlying varobj_update call looks to see if there is a difference
>> between the current value and a refreshed value.  Since varobj_set_value
>> actually changes both the internal value and the actual value, varobj_update
>> does not add the variable to the changelist.
> 
> 
> The real question is: is it really necessary for an assignment to show up 
> in the udpate list. IMO, it doesn't matter, because the caller will know if 
> the assignment succeeded or failed. If it failed, it'll have an error 
> message from MI. Otherwise, it knows that it worked and all it needs to do 
> is fetch the value of this variable (to get the right display format) and
> update the displayed value on the screen. There's no reason to do an 
> update, which is not a cheap operation.
> 
> I really don't know what to make of this. I don't think this is really 
> necessary. It seems like a substitute for error checking.
> 
> Perhaps Alain can comment on why this is necessary with Eclipse?

To play the devil's devil advocate ...

Consider a memory mapped register with sticky bits (no I'm not just 
making this up, I recently got asked this exact question - I've a vague 
recollection of complaints about gdb's current behavior in this regard).

I think ``the right thing'' is:

- the expression evaluation writes the value all the way through to the 
target
- gdb invalidates everything - memory and register caches, varobj
- gdb evaluates all variable objects including that just written value.
- -var-update lists all values that changed

The result could even be that that the modified variable didn't change 
because that modified variable is truely ``stuck'' or that some of the 
modified value is restored.

So what does the MI and the patch do in this case?

Andrew