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


Keith Seitz 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?
> 
> Keith

Consider the following scenario.  An application has output windows showing a number
of variables.  Some of these output variables are aliases of one another
(e.g. *p which points to a[5] which is also being shown).  The application
kicks off a separate input field operation that changes the value of a[5].
Now, the application knows it changed a[5], but doesn't necessarily know about
the current alias to *p.  With patch, if the -var-update is performed after the -var-assign, both
values will show that they need update.  Without the patch, only the *p value will
show up (the original assignment won't).  Arguably, the application could track
this, but it seems to make sense to keep it clean.  The "change value" window
could simply signal that a value has changed and let any corresponding
windows issue their own updates.

-- Jeff J.


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