From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 16480 invoked by alias); 2 Feb 2009 16:51:09 -0000 Received: (qmail 16472 invoked by uid 22791); 2 Feb 2009 16:51:08 -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; Mon, 02 Feb 2009 16:51:00 +0000 Received: (qmail 1837 invoked from network); 2 Feb 2009 16:50:58 -0000 Received: from unknown (HELO orlando.local) (pedro@127.0.0.2) by mail.codesourcery.com with ESMTPA; 2 Feb 2009 16:50:58 -0000 From: Pedro Alves To: gdb-patches@sourceware.org, Eli Zaretskii Subject: Re: [1/2] Inspect extra signal information Date: Mon, 02 Feb 2009 16:51:00 -0000 User-Agent: KMail/1.9.10 References: <200901121846.51709.pedro@codesourcery.com> <200901121852.06948.pedro@codesourcery.com> In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200902021652.28152.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/msg00029.txt.bz2 On Monday 12 January 2009 19:39:09, Eli Zaretskii wrote: > > From: Pedro Alves > > Date: Mon, 12 Jan 2009 18:52:06 +0000 > > > > * defs.h (enum lval_type): New value: lval_computed. > > * value.h (struct lval_funcs): New type. > > (allocate_computed_value, value_computed_funcs) > > (value_computed_closure): New declarations. > > * value.c (struct value): Add a structure to the location union > > for computed lvalues, containing 'funcs' and 'closure' members. > > (allocate_computed_value, value_computed_funcs) > > (value_computed_closure): New functions. > > I think this introduces a general-purpose infrastructure that must be > documented in gdbint.texinfo. > I'm taking a stab at this. I don't see struct value documented in the internals manual though. What kind of detail do you require here? I'm thinking of adding a "Values" section somewhere, don't know where yet. @section Values @value{GDBN} uses @code{struct value}, or simply named a @dfn{value}, 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 data stored in or accessed through the value. A value is in addition descriminated by its lvalue-ness, given its @code{enum lval_type} enumeration: @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. @item @code{lval_computed} These are values with arbitrary functions to handle reads and writes, and "copy operators" and "destructors". 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 specifies specialized read, write, copy and release callbacks, described by the @code{struct lval_funcs} struture declared in @file{value.h} to the @code{allocate_computed_value} function. An example use is the implementations of the @code{$_siginfo} convenience variable in @file{infrun.c}. @end table @subsection Lazy values ... -- Pedro Alves