This is the mail archive of the gdb-patches@sources.redhat.com mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Patch for gdb/mi problem 702


Andrew Cagney wrote:
> 
> > 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?
> 

I think we are ok.

The -var-update code calls value_of_root at the top to get a "new"
value before comparing.  This operation ends up calling gdb_evaluate_expression
which should handle fetching the real value and any sticky bits should be
set properly.

The new code now looks at the "updated" flag which I added.  If this
flag is on, it puts the item on the list.  This causes the current varobj value to
be updated with value "new" so all should be fine.

-- Jeff J.

> Andrew


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]