From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 8568 invoked by alias); 23 Jun 2009 13:49:58 -0000 Received: (qmail 8558 invoked by uid 22791); 23 Jun 2009 13:49:57 -0000 X-SWARE-Spam-Status: No, hits=-2.5 required=5.0 tests=AWL,BAYES_00 X-Spam-Check-By: sourceware.org Received: from NaN.false.org (HELO nan.false.org) (208.75.86.248) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Tue, 23 Jun 2009 13:49:50 +0000 Received: from nan.false.org (localhost [127.0.0.1]) by nan.false.org (Postfix) with ESMTP id 2CBF310F2B; Tue, 23 Jun 2009 13:49:43 +0000 (GMT) Received: from caradoc.them.org (209.195.188.212.nauticom.net [209.195.188.212]) by nan.false.org (Postfix) with ESMTP id F35E610DC5; Tue, 23 Jun 2009 13:49:42 +0000 (GMT) Received: from drow by caradoc.them.org with local (Exim 4.69) (envelope-from ) id 1MJ6NX-0003Qw-3W; Tue, 23 Jun 2009 09:49:39 -0400 Date: Tue, 23 Jun 2009 13:49:00 -0000 From: Daniel Jacobowitz To: Ulrich Weigand Cc: Doug Evans , gdb-patches@sourceware.org Subject: Re: Per-type architecture (Re: [10/15] Basic value access routines) Message-ID: <20090623134938.GA12312@caradoc.them.org> Mail-Followup-To: Ulrich Weigand , Doug Evans , gdb-patches@sourceware.org References: <20090622205935.GA5900@caradoc.them.org> <200906230041.n5N0fMYW019073@d12av02.megacenter.de.ibm.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200906230041.n5N0fMYW019073@d12av02.megacenter.de.ibm.com> User-Agent: Mutt/1.5.17 (2008-05-11) 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-06/txt/msg00604.txt.bz2 On Tue, Jun 23, 2009 at 02:41:22AM +0200, Ulrich Weigand wrote: > - for values of bitfield type, the bitfield byte order (as you mention) We don't actually need the architecture for this, given the type. But that's only because the way we record this in types requires the architecture when building the type; I've seriously considered rearranging it so that the type was architecture neutral and the value architecture dependent. But it seems too fragile to touch without a better reason... > - for values of floating point type, the floating point format (which > today is sometimes, but not always, attached to the type) Huh, when isn't it attached to the type? > However, for the *first* set of properties it doesn't seem to make sense > to require this information to be provided apart from the value object; > there is just about nothing you can do with the value if you don't even > understand how to interpret its contents. This is the part I'm not sure about. An int32_t from a BE application and an int32_t from an LE application are clearly distinguished values, but I think they're of the same type. However, I don't feel so strongly about this to object to your patch. > For example, one class of such uses is to find some random type in order > to construct an index value to pass to value_subscript (or value_ptradd) > or the like. We actually know the *offset* as numerical value, but finding > the *type* to form a value object out of the offset is hard. In this case, > it seems to me the interface of our helper routines is simply ill-defined: > value_subscript does not even *look* at the type of the index operand, the > only thing it does to the value is calling value_as_long! So simply changing > the interface to take a LONGEST instead of value fixes this class of problems > while making the callers simpler. For my two cents, I would have preferred we had a uniform internal value/type system where everything operated on struct value. Then you know exactly what any value_* routine expects: always value(s). That's why I wanted frame unwinding to use values instead of buffers. > This seems even uglier to me :-) Maybe I'm just looking at this particular > target-description case a bit differently, but for me tdesc_type is not > "inventing a new ad-hoc representation of types", it is simply a 1:1 in-memory > representation of the XML contents without any GDB-specific reinterpretation > -- think something like "DOM tree" structures. In fact, if it weren't that > we want to avoid excessive dependencies on XML libraries, I'd argue we should > just parse XML into a standard DOM tree representation as provided by those. Good point. Yes, I'd much preferred we had a DOM; I looked at several minimalist C DOM implementations, but couldn't find one that I trusted to work nearly as well as expat. Since expat ended up external to the GDB source tree anyway, maybe it would have been wiser to pick GNOME's libxml2. The duplication of type layouts bugs me, but let's go with it. Afterwards, I'll do a second merge into our internal tree and see what the extra type support looks like. -- Daniel Jacobowitz CodeSourcery