From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 24101 invoked by alias); 15 Jun 2009 16:35:21 -0000 Received: (qmail 24093 invoked by uid 22791); 15 Jun 2009 16:35:20 -0000 X-SWARE-Spam-Status: No, hits=-1.5 required=5.0 tests=AWL,BAYES_00,J_CHICKENPOX_46,SARE_MSGID_LONG40,SPF_PASS X-Spam-Check-By: sourceware.org Received: from smtp-out.google.com (HELO smtp-out.google.com) (216.239.33.17) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Mon, 15 Jun 2009 16:35:13 +0000 Received: from spaceape8.eur.corp.google.com (spaceape8.eur.corp.google.com [172.28.16.142]) by smtp-out.google.com with ESMTP id n5FGZAwA031331 for ; Mon, 15 Jun 2009 17:35:10 +0100 Received: from yw-out-1718.google.com (ywm5.prod.google.com [10.192.13.5]) by spaceape8.eur.corp.google.com with ESMTP id n5FGZ7tg008907 for ; Mon, 15 Jun 2009 09:35:08 -0700 Received: by yw-out-1718.google.com with SMTP id 5so2277940ywm.18 for ; Mon, 15 Jun 2009 09:35:07 -0700 (PDT) MIME-Version: 1.0 Received: by 10.90.70.6 with SMTP id s6mr2040800aga.18.1245083707025; Mon, 15 Jun 2009 09:35:07 -0700 (PDT) In-Reply-To: <200906091519.n59FJjNr000518@d12av02.megacenter.de.ibm.com> References: <200906091519.n59FJjNr000518@d12av02.megacenter.de.ibm.com> Date: Mon, 15 Jun 2009 16:35:00 -0000 Message-ID: Subject: Re: [10/15] Basic value access routines From: Doug Evans To: Ulrich Weigand Cc: gdb-patches@sourceware.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-System-Of-Record: true 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/msg00392.txt.bz2 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. [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.] Thoughts?