From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 18940 invoked by alias); 23 Jun 2009 00:41:46 -0000 Received: (qmail 18927 invoked by uid 22791); 23 Jun 2009 00:41:45 -0000 X-SWARE-Spam-Status: No, hits=-1.7 required=5.0 tests=AWL,BAYES_00,MSGID_FROM_MTA_HEADER,SPF_PASS X-Spam-Check-By: sourceware.org Received: from mtagate4.de.ibm.com (HELO mtagate4.de.ibm.com) (195.212.29.153) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Tue, 23 Jun 2009 00:41:38 +0000 Received: from d12nrmr1607.megacenter.de.ibm.com (d12nrmr1607.megacenter.de.ibm.com [9.149.167.49]) by mtagate4.de.ibm.com (8.14.3/8.13.8) with ESMTP id n5N0fNln231790 for ; Tue, 23 Jun 2009 00:41:23 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 n5N0fNbM2809896 for ; Tue, 23 Jun 2009 02:41:23 +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 n5N0fNkd019078 for ; Tue, 23 Jun 2009 02:41:23 +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 n5N0fMYW019073; Tue, 23 Jun 2009 02:41:22 +0200 Message-Id: <200906230041.n5N0fMYW019073@d12av02.megacenter.de.ibm.com> Received: by tuxmaker.boeblingen.de.ibm.com (sSMTP sendmail emulation); Tue, 23 Jun 2009 02:41:22 +0200 Subject: Re: Per-type architecture (Re: [10/15] Basic value access routines) To: drow@false.org (Daniel Jacobowitz) Date: Tue, 23 Jun 2009 00:41:00 -0000 From: "Ulrich Weigand" Cc: dje@google.com (Doug Evans), gdb-patches@sourceware.org In-Reply-To: <20090622205935.GA5900@caradoc.them.org> from "Daniel Jacobowitz" at Jun 22, 2009 04:59:35 PM 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/msg00595.txt.bz2 Daniel Jacobowitz wrote: > I think you're simplifying the wrong thing - it probably simplifies > your patches to remove the global architecture a lot, but I think it > makes the rest of GDB more complicated in exchange. Why should types > have an associated architecture, in and of themselves? Let's start by looking at *values* first. In order to perform just about any operations on a value, in fact even to understand just what the contents of a value objects even *mean*, there's a bunch of information we need: - for (nearly) every value, the byte order - for values of bitfield type, the bitfield byte order (as you mention) - for values of floating point type, the floating point format (which today is sometimes, but not always, attached to the type) - for values of pointer/reference type, the architecture-specific semantics of converting target pointer values to and from GDB internal addresses - for values of function pointer type, the architecture-specific semantics of finding the target function (function descriptors etc.) - for values of C++ specific types (classes, pointers-to-member etc.), how they are encoded according to the platform ABI In addition, when printing values, we need additional data on: - how to format target addresses for printing - how to interpret requests of printing the value "as something else" (e.g. as floating point, or as string, or as instruction disassembly) rather than its base type All this information today is provided via gdbarch properties accessed (just about always) from current_gdbarch. For the second set of properties, one might argue that this is data that *should* properly be provided as extra information in addition to the value itself -- you print the value "as something". For example, the printing routines might carry a gdbarch as print_options. 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. If we agree that it should be possible to retrieve those properties from a value object itself, then the question becomes if they should attach to single values, or rather types. My initial patch set implemented the first approach. However, on further thought, I now tend to prefer the second option. In the end, a "type" is nothing else but a set of rules how to interpret the contents of uniform classes of values, right? And all the above properties are of that form ... Now, those properties could just be attached to the type itself, without completing the link to a gdbarch object. In a way, this seems to be what was attempted by TYPE_FLOATFORMAT. However, implementing this looks to be at least as complex as going all the way to gdbarch -- e.g. if you make byte order a property of the type, you still need to wait to create types until you know what target architecture to create them for. Plus, at this point it isn't actually hard to make that transition; nearly all types are *already* associated with either an objfile (and thus its architecture indirectly), or explicitly with an architecture as target- specific types. There are still a couple of places where we randomly access builtin_type_int32 or the like, but it seems they can all be restructured to avoid such accesses *while making the code simpler!* 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. On the other hand, actually going all the way to ensure every type is associated with a gdbarch makes several other simplifications possible: - we can continue to provide a simple lookup_pointer_type interface -- if a type knows its own architecture, it knows the representation of pointer types to itself! - we can continue to have architecture-specific properties of *types* defined via gdbarch callbacks, e.g. address classes > Maybe we can take a similar approach here. Instead of inventing a new > ad-hoc representation of types, use types, but make a copy with the > right architecture when they're accessed. WDYT? 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. Looking at this this way, serialization/deserialization of XML into and out of those "DOM tree" structures *should not* involve too much GDB specifics like GDB private data structures, but simply follow the self-describing property of the XML format ... (Or stating it another way, I think the tdesc_type patch I posted is a good idea even if we decide in the end to not associate every type with an architecture.) Thoughts? Bye, Ulrich -- Dr. Ulrich Weigand GNU Toolchain for Linux on System z and Cell BE Ulrich.Weigand@de.ibm.com