Re: [RFC] varobj deletion after the binary has changed

[Nick Roberts <nickrob at snap dot net dot nz>]

 > The C seems reasonable to me; though let's not check it in until we
 > have a documentation update to go with it, if possible.  How about
 > under the -var-update section, by the example which uses
 > in_scope="true"?

How about this?

-- 
Nick                                           http://www.inet.net.nz/~nickrob


2007-02-09  Nick Roberts  <nickrob@snap.net.nz>

	* gdb.texinfo (GDB/MI Variable Objects): Describe meanings of
	values for in_scope.  Mention that only root variables can be
	updated.
	(GDB/MI Development and Front Ends): Explain new values may be
	added to existing fields.


*** gdb.texinfo	08 Feb 2007 13:24:03 +1300	1.384
--- gdb.texinfo	09 Feb 2007 08:27:39 +1300	
*************** New MI commands may be added.
*** 17732,17737 ****
--- 17732,17741 ----
  @item
  New fields may be added to the output of any MI command.
  
+ @item
+ The range of values for fields with specified values e.g in_scope,
+ type_changed may be extended.
+ 
  @c The format of field's content e.g type prefix, may change so parse it
  @c   at your own risk.  Yes, in general?
  
*************** subsequent @code{-var-update} list.
*** 19972,19987 ****
  
  Reevaluate the expressions corresponding to the variable object
  @var{name} and all its direct and indirect children, and return the
! list of variable objects whose values have changed. Here,
! ``changed'' means that the result of @code{-var-evaluate-expression} before
! and after the @code{-var-update} is different.  If @samp{*} is used
! as the variable object names, all existing variable objects are
! updated.  The option @var{print-values} determines whether both names 
! and values, or just names are printed.  The possible values of
! this options are the same as for @code{-var-list-children}
! (@pxref{-var-list-children}).  It is recommended to use the
! @samp{--all-values} option, to reduce the number of MI commands needed
! on each program stop.
  
  
  @subsubheading Example
--- 19976,19991 ----
  
  Reevaluate the expressions corresponding to the variable object
  @var{name} and all its direct and indirect children, and return the
! list of variable objects whose values have changed.  @var{name} must
! be a root variable object.  Here, ``changed'' means that the result of
! @code{-var-evaluate-expression} before and after the
! @code{-var-update} is different.  If @samp{*} is used as the variable
! object names, all existing variable objects are updated.  The option
! @var{print-values} determines whether both names and values, or just
! names are printed.  The possible values of this options are the same
! as for @code{-var-list-children} (@pxref{-var-list-children}).  It is
! recommended to use the @samp{--all-values} option, to reduce the
! number of MI commands needed on each program stop.
  
  
  @subsubheading Example
*************** type_changed="false"@}]
*** 19997,20002 ****
--- 20001,20027 ----
  (gdb)
  @end smallexample
  
+ The field in_scope may take three values:
+ 
+ @table @code
+ @item "true"
+ The variable object's current value is valid.
+ 
+ @item "false"
+ The variable object does not currently hold a valid value but it
+ may hold one in the future it's associated expression comes back into scope.
+ 
+ @item "invalid"
+ The variable object no longer holds a valid value.
+ This can occur when the executable file being debugged has changed,
+ either through recompilation or by using the @value{GDBN} @code{file}
+ command.  The front end should normally choose to delete these variable
+ objects.
+ @end table
+ 
+ In the future new values may be added to this list so the front should
+ be prepared for this possibility.  @xref{GDB/MI Development and Front Ends, ,@sc{GDB/MI} Development and Front Ends}.
+ 
  @c %%%%%%%%%%%%%%%%%%%%%%%%%%%% SECTION %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
  @node GDB/MI Data Manipulation
  @section @sc{gdb/mi} Data Manipulation