Re: Patch for gdb/mi problem 702

Andrew Cagney
2002-10-22T01:40:58Z

> 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