From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 6224 invoked by alias); 5 Feb 2009 01:14:11 -0000 Received: (qmail 6216 invoked by uid 22791); 5 Feb 2009 01:14:09 -0000 X-SWARE-Spam-Status: No, hits=-2.4 required=5.0 tests=AWL,BAYES_00,SPF_PASS X-Spam-Check-By: sourceware.org Received: from mail.codesourcery.com (HELO mail.codesourcery.com) (65.74.133.4) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Thu, 05 Feb 2009 01:14:02 +0000 Received: (qmail 21195 invoked from network); 5 Feb 2009 01:13:59 -0000 Received: from unknown (HELO orlando) (pedro@127.0.0.2) by mail.codesourcery.com with ESMTPA; 5 Feb 2009 01:13:59 -0000 From: Pedro Alves To: gdb-patches@sourceware.org, Eli Zaretskii Subject: Re: [1/2] Inspect extra signal information Date: Thu, 05 Feb 2009 01:14:00 -0000 User-Agent: KMail/1.9.10 References: <200901121846.51709.pedro@codesourcery.com> <200902021652.28152.pedro@codesourcery.com> In-Reply-To: MIME-Version: 1.0 Content-Type: Multipart/Mixed; boundary="Boundary-00=_d1jiJwE/tX8XOsv" Message-Id: <200902050114.05103.pedro@codesourcery.com> X-IsSubscribed: yes Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org X-SW-Source: 2009-02/txt/msg00115.txt.bz2 --Boundary-00=_d1jiJwE/tX8XOsv Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-length: 2002 On Monday 02 February 2009 21:04:34, Eli Zaretskii wrote: > > From: Pedro Alves > > I don't see struct value documented in > > the internals manual though. What kind of detail do you require here? > > Exactly the kind you described. Great. > > I'm thinking of adding a "Values" section somewhere, don't know > > where yet. > > The place doesn't matter much, since the internals manual is "work in > progress", and looks more like a car crash than a concise document. > :-) There doesn't seem there's a good way to place it, since values are used for many things, so I made it a new chapter. I placed it even before Stack Frames, because frame handling uses struct value. > > @item @code{lval_computed} > > > > These are values with arbitrary functions to handle reads and writes, > > Please lose the empty line between the @item and its description. > Done. > > and "copy operators" and "destructors". They allow creating > > Please use ``this kind of quoting'' in Texinfo, not "this kind". > Done. ( it shows I didn't write that in emacs :-) ) > > described by the @code{struct lval_funcs} struture declared in > ^^^^^^^^ > A typo. > Fixed. > > @file{value.h} to the @code{allocate_computed_value} function. An > > What does it mean "declared in value.h to the allocate_computed_value > function"? It means I wrote a too long sentence, and lost sense somewhere along the way. :-) "The creator of such a value specifies specialized read (...) callbacks (...) to the @code{allocate_computed_value} function." I've rewriten this. I think it's clearer now. > Perhaps add a few words describing `struct lval_funcs', or maybe just > showing a simple example would be enough. I've added an example. > A couple of index entries for this section will also help. I've added them. > Thanks again for working on this. Thanks for the speedy review. Here's a proper patch. Does it look OK? -- Pedro Alves --Boundary-00=_d1jiJwE/tX8XOsv Content-Type: text/x-diff; charset="iso 8859-15"; name="lval_computed_docs.diff" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="lval_computed_docs.diff" Content-length: 3614 2009-02-04 Pedro Alves * gdbint.texinfo (Values): New chapter. --- gdb/doc/gdbint.texinfo | 95 +++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 95 insertions(+) Index: src/gdb/doc/gdbint.texinfo =================================================================== --- src.orig/gdb/doc/gdbint.texinfo 2009-02-03 19:20:40.000000000 +0000 +++ src/gdb/doc/gdbint.texinfo 2009-02-05 01:11:31.000000000 +0000 @@ -76,6 +76,7 @@ as the mechanisms that adapt @value{GDBN * Algorithms:: * User Interface:: * libgdb:: +* Values:: * Stack Frames:: * Symbol Handling:: * Language Support:: @@ -1834,6 +1835,100 @@ the query interface. Each function is p builder. The result of the query is constructed using that builder before the query function returns. +@node Values +@chapter Values +@section Values + +@cindex values +@cindex @code{value} structure +@value{GDBN} uses @code{struct value}, or @dfn{values}, as an internal +abstraction for the representation of a variety of inferior objects +and @value{GDBN} convenience objects. + +Values have an associated @code{struct type}, that describes a virtual +view of the raw data or object stored in or accessed through the +value. + +A value is in addition descriminated by its lvalue-ness, given its +@code{enum lval_type} enumeration type: + +@cindex @code{lval_type} enumeration, for values. +@table @code +@item @code{not_lval} +This value is not an lval. It can't be assigned to. + +@item @code{lval_memory} +This value represents an object in memory. + +@item @code{lval_register} +This value represents an object that lives in a register. + +@item @code{lval_internalvar} +Represents the value of an internal variable. + +@item @code{lval_internalvar_component} +Represents part of a gdb internal variable. E.g., a structure field. + +@cindex computed values +@item @code{lval_computed} +These are ``computed'' values. They allow creating specialized value +objects for specific purposes, all abstracted way from the the core +value support code. The creator of such a value writes specialized +functions to handle the reading and writing to/from the value's +backend data, and optionally, a ``copy operator'' and a +``destructor''. + +Pointers to these functions are stored in a @code{struct lval_funcs} +instance (declared in @file{value.h}), and passed to the +@code{allocate_computed_value} function, as in the example below. + +@smallexample +static void +nil_value_read (struct value *v) +@{ + /* This callback reads data from some backend, and stores it in V. + In this case, we always read null data. You'll want to fill in + something more interesting. */ + + memset (value_contents_all_raw (v), + value_offset (v), + TYPE_LENGTH (value_type (v))); +@} + +static void +nil_value_write (struct value *v, struct value *fromval) +@{ + /* Takes the data from FROMVAL and stores it in the backend of V. */ + + to_oblivion (value_contents_all_raw (fromval), + value_offset (v), + TYPE_LENGTH (value_type (fromval))); +@} + +static struct lval_funcs nil_value_funcs = + @{ + nil_value_read, + nil_value_write + @}; + +struct value * +make_nil_value (void) +@{ + struct type *type; + struct value *v; + + type = make_nils_type (); + v = allocate_computed_value (type, &nil_value_funcs, NULL); + + return v; +@} +@end smallexample + +See the implementation of the @code{$_siginfo} convenience variable in +@file{infrun.c} as a real example use of lval_computed. + +@end table + @node Stack Frames @chapter Stack Frames --Boundary-00=_d1jiJwE/tX8XOsv--