From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 32696 invoked by alias); 15 Jun 2009 16:59:15 -0000 Received: (qmail 32683 invoked by uid 22791); 15 Jun 2009 16:59:14 -0000 X-SWARE-Spam-Status: No, hits=-1.4 required=5.0 tests=AWL,BAYES_00,J_CHICKENPOX_46,MSGID_FROM_MTA_HEADER,SPF_PASS X-Spam-Check-By: sourceware.org Received: from mtagate3.de.ibm.com (HELO mtagate3.de.ibm.com) (195.212.29.152) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Mon, 15 Jun 2009 16:59:07 +0000 Received: from d12nrmr1607.megacenter.de.ibm.com (d12nrmr1607.megacenter.de.ibm.com [9.149.167.49]) by mtagate3.de.ibm.com (8.14.3/8.13.8) with ESMTP id n5FGwtpZ230312 for ; Mon, 15 Jun 2009 16:58:55 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 n5FGwsvW3326152 for ; Mon, 15 Jun 2009 18:58:54 +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 n5FGwsIC026840 for ; Mon, 15 Jun 2009 18:58:54 +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 n5FGwrN6026829; Mon, 15 Jun 2009 18:58:53 +0200 Message-Id: <200906151658.n5FGwrN6026829@d12av02.megacenter.de.ibm.com> Received: by tuxmaker.boeblingen.de.ibm.com (sSMTP sendmail emulation); Mon, 15 Jun 2009 18:58:53 +0200 Subject: Re: [10/15] Basic value access routines To: dje@google.com (Doug Evans) Date: Mon, 15 Jun 2009 16:59:00 -0000 From: "Ulrich Weigand" Cc: gdb-patches@sourceware.org In-Reply-To: from "Doug Evans" at Jun 15, 2009 09:35:06 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/msg00393.txt.bz2 Doug Evans wrote: > On Tue, Jun 9, 2009 at 8:19 AM, Ulrich Weigand wrote: > > Hello, > > > > a number of core data conversion routines deeply buried in the > > call chain implicitly use current_gdbarch to determine the format > > of the data (address/pointer conversion, floating point formats). > > > > This patch adds an explicit gdbarch argument to the following > > routines to eliminate that use, and updates all call sites: > > > > - unpack_long/unpack_double/unpack_pointer/pack_long > > - extract_typed_address/store_typed_address/read_memory_typed_address > > - extract_typed_floating/store_typed_floating/convert_typed_floating > > - floatformat_from_type > > Can a struct type (or struct main_type) ever be associated with more > than one architecture? > [And if they can, is that correct given things like struct > main_type.fields, struct type.length (and a few others)?] > > And if a struct type (or struct main_type) can (or should) only be > associated with one architecture can we make it so that we can obtain > the architecture given the type? > That would seem to simplify things. That was one of main design questions of this whole effort. The problems with associating a gdbarch with a type (and subsequently using the arch of a value's type as the arch of the value) is that: - We have architecture-independent types (e.g. builtin_type_void, builtin_type_int32 etc.), and last time we discussed this, the consensus was that we want to keep this option - The bulk of types is read in from symbol files -- these could be associated with the generic objfile arch at this point, but that is not sufficient as a value arch. For example, the objfile arch does not contain specific register number associations; those are only determined by a run-time arch from the target. For values refering to registers, we need the latter however. > [I realize there's type->main_type->objfile->gdbarch, but it's not > clear to me that this will always be the correct one to use. Maybe it > is. > I also realize struct main_type is space critical, struct type is not > marked as such but maybe it is too. > I'd still hate to lose the simplicity gained by being able to > determine an arch given just the type. > Maybe there's a way to have both.] Those are additional minor issues; the type structures are indeed space critical, and the main_type->objfile pointer is not always set (e.g. for builtin types), but we could use a union of a objfile pointer and a gdbarch pointer. That major problems are the ones described above -- at the time a type is allocated, we generally do not know the correct architecture to use for values of this type. Bye, Ulrich -- Dr. Ulrich Weigand GNU Toolchain for Linux on System z and Cell BE Ulrich.Weigand@de.ibm.com