From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 25339 invoked by alias); 23 Jun 2009 17:06:41 -0000 Received: (qmail 25308 invoked by uid 22791); 23 Jun 2009 17:06:38 -0000 X-SWARE-Spam-Status: No, hits=-1.4 required=5.0 tests=AWL,BAYES_00,MSGID_FROM_MTA_HEADER,SPF_SOFTFAIL X-Spam-Check-By: sourceware.org Received: from mtagate1.de.ibm.com (HELO mtagate1.de.ibm.com) (195.212.17.161) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Tue, 23 Jun 2009 17:06:25 +0000 Received: from d12nrmr1607.megacenter.de.ibm.com (d12nrmr1607.megacenter.de.ibm.com [9.149.167.49]) by mtagate1.de.ibm.com (8.13.1/8.13.1) with ESMTP id n5NH6MKQ015988 for ; Tue, 23 Jun 2009 17:06:22 GMT Received: from d12av02.megacenter.de.ibm.com (d12av02.megacenter.de.ibm.com [9.149.165.228]) by d12nrmr1607.megacenter.de.ibm.com (8.13.8/8.13.8/NCO v9.2) with ESMTP id n5NH6MKf3088624 for ; Tue, 23 Jun 2009 19:06:22 +0200 Received: from d12av02.megacenter.de.ibm.com (loopback [127.0.0.1]) by d12av02.megacenter.de.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id n5NH6HfR028016 for ; Tue, 23 Jun 2009 19:06:22 +0200 Received: from tuxmaker.boeblingen.de.ibm.com (tuxmaker.boeblingen.de.ibm.com [9.152.85.9]) by d12av02.megacenter.de.ibm.com (8.12.11.20060308/8.12.11) with SMTP id n5NH0Op5017747; Tue, 23 Jun 2009 19:00:24 +0200 Message-Id: <200906231700.n5NH0Op5017747@d12av02.megacenter.de.ibm.com> Received: by tuxmaker.boeblingen.de.ibm.com (sSMTP sendmail emulation); Tue, 23 Jun 2009 19:00:24 +0200 Subject: Re: Per-type architecture (Re: [10/15] Basic value access routines) To: drow@false.org (Daniel Jacobowitz) Date: Tue, 23 Jun 2009 17:06:00 -0000 From: "Ulrich Weigand" Cc: dje@google.com (Doug Evans), gdb-patches@sourceware.org In-Reply-To: <20090623134938.GA12312@caradoc.them.org> from "Daniel Jacobowitz" at Jun 23, 2009 09:49:38 AM MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit 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/msg00618.txt.bz2 Daniel Jacobowitz wrote: > 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... We *do* need the architecture to interpret bitfield types; see e.g. the comment in gdbtypes.h: /* Position of this field, counting in bits from start of containing structure. For gdbarch_bits_big_endian=1 targets, it is the bit offset to the MSB. For gdbarch_bits_big_endian=0 targets, it is the bit offset to the LSB. For a range bound or enum value, this is the value itself. */ int bitpos; and the various references to gdbarch_bits_big_endian (current_gdbarch) in unpack_field_as_long, modify_field, etc. There's no way to operate on a bitfield value without knowledge of this property. > > - 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? Most of the time :-) In fact, none of the types created by symbol readers ever has a non-NULL TYPE_FLOATFORMAT. It is only set for builtin types generated via gdbtypes.c:build_flt (and the builtin_type_ia64_ext special case). For every other type, the floatformat is computed on the fly in floatformat_from_type via floatformat_from_length (again consulting gdbarch properties of current_gdbarch). > > 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. Well, I strongly feel that byte order needs to determinable from the *value* object one way or the other. Whether this is done by making byte order a property of the value's *type*, or rather by making byte order a property of the value itself in addition to its type, I don't feel very strongly about; this seems to me to be more a question of what's more convenient to use. If we decide to associate a gdbarch with a type anyway to cover the other properties mentioned, then it seems simpler to use it for byte order too. However, even then we could still have an additional byte-order property of the value that would override the type's, if we think that necessary ... > > 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. I agree, but those naturally *have* types ... I guess we can discuss this with more specificity once I actually post patches about value_subscript etc. > > 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. OK, thanks. I've checked the patch in now. Bye, Ulrich -- Dr. Ulrich Weigand GNU Toolchain for Linux on System z and Cell BE Ulrich.Weigand@de.ibm.com