This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
Re: [RFC] varobj deletion after the binary has changed
- From: Nick Roberts <nickrob at snap dot net dot nz>
- To: Denis PILAT <denis dot pilat at st dot com>
- Cc: Eli Zaretskii <eliz at gnu dot org>, drow at false dot org, gdb-patches at sourceware dot org
- Date: Tue, 13 Feb 2007 13:11:05 +1300
- Subject: Re: [RFC] varobj deletion after the binary has changed
- References: <20070123124457.GA1600@nevyn.them.org> <45B63A49.4010609@st.com> <45B8E8A8.9040904@st.com> <17849.12231.246980.478169@kahikatea.snap.net.nz> <20070125232731.GA30178@nevyn.them.org> <45BDEAEC.1050006@st.com> <17854.28971.170898.231523@kahikatea.snap.net.nz> <45C0B042.9040308@st.com> <17857.2617.164646.935952@kahikatea.snap.net.nz> <45C1B78C.60605@st.com> <20070208164103.GA13544@nevyn.them.org> <17867.31476.627368.180759@kahikatea.snap.net.nz> <uy7n79w0k.fsf@gnu.org> <45D05B3B.5050408@st.com>
> Thanks you for the documentation update.
> Hereby is 2 patches I would like to commit, the C part and the new . exp
> file.
> I change the .exp file with your comment, with a newer copyright notice,
> and with including value field in output of -var-create.
> I also changed a comment plus typos in the C code.
>
> Daniel already approved the sources, Eli is near to be fine with the doc.
> Could have a look once more into the following, at least for the
> ChangeLog entry ?
> Then how could we synchronize our commit ?
I've committed my documentation with requested changes (see below). All you
need to do is commit yours.
> 2007-02-12 Denis Pilat <denis.pilat@st.com>
>
> * gdb.mi/mi-var-invalidate.exp: New files.
New file.
> 2007-02-12 Denis Pilat <denis.pilat@st.com>
>
> * varobj.c (struct varobj_root): Add is_valid member.
> (varobj_get_type): Check for invalid varobj.
> (varobj_get_attributes): Likewise.
> (variable_editable):Likewise.
> (varobj_update): Likewise plus use an enum for returned error values.
> (new_root_variable): Set root varobj as valid by default.
> (varobj_invalidate): New function.
> * varobj.h (enum varobj_update_error): New enum.
> (varobj_invalidate): New function.
duplicate entry
> * symfile.c (clear_symtab_users): Use varobj_invalidate.
> * mi/mi-cmd-var.c (varobj_update_one): Change returned type to void and
> use of new enum varobj_update_error to deal with errors.
* varobj.h (enum varobj_update_error): New enum.
* varobj.c (struct varobj_root): Add is_valid member.
(varobj_get_type): Check for invalid varobj.
(varobj_get_attributes): Likewise.
(variable_editable):Likewise.
(varobj_update): Likewise. Use varobj_update_error.
(new_root_variable): Set root varobj as valid by default.
(varobj_invalidate): New function.
* symfile.c (clear_symtab_users): Use varobj_invalidate.
* mi/mi-cmd-var.c (varobj_update_one): Change return type to void.
Use varobj_update_error.
(Suggestion)
--
Nick http://www.inet.net.nz/~nickrob
2007-02-13 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 13 Feb 2007 12:48:47 +1300 1.385
--- gdb.texinfo 10 Feb 2007 10:15:05 +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.,
+ @code{in_scope} (@pxref{-var-update}) 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,20029 ----
(gdb)
@end smallexample
+ @anchor{-var-update}
+ 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 if its 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