From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 25635 invoked by alias); 13 Jun 2007 14:10:17 -0000 Received: (qmail 25619 invoked by uid 22791); 13 Jun 2007 14:10:16 -0000 X-Spam-Check-By: sourceware.org Received: from mtagate1.de.ibm.com (HELO mtagate1.de.ibm.com) (195.212.29.150) by sourceware.org (qpsmtpd/0.31) with ESMTP; Wed, 13 Jun 2007 14:10:11 +0000 Received: from d12nrmr1607.megacenter.de.ibm.com (d12nrmr1607.megacenter.de.ibm.com [9.149.167.49]) by mtagate1.de.ibm.com (8.13.8/8.13.8) with ESMTP id l5DEA8h2047488 for ; Wed, 13 Jun 2007 14:10:08 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 v8.3) with ESMTP id l5DEA88V3997780 for ; Wed, 13 Jun 2007 16:10:08 +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 l5DEA7w1012690 for ; Wed, 13 Jun 2007 16:10:08 +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 l5DEA7WJ012687; Wed, 13 Jun 2007 16:10:07 +0200 Message-Id: <200706131410.l5DEA7WJ012687@d12av02.megacenter.de.ibm.com> Received: by tuxmaker.boeblingen.de.ibm.com (sSMTP sendmail emulation); Wed, 13 Jun 2007 16:10:07 +0200 Subject: Re: [5/10] Add "explicit size" types to builtin_type To: drow@false.org (Daniel Jacobowitz) Date: Wed, 13 Jun 2007 14:10:00 -0000 From: "Ulrich Weigand" Cc: gdb-patches@sourceware.org In-Reply-To: <20070612163217.GA6815@caradoc.them.org> from "Daniel Jacobowitz" at Jun 12, 2007 12:32:17 PM X-Mailer: ELM [version 2.5 PL2] 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: 2007-06/txt/msg00228.txt.bz2 Daniel Jacobowitz wrote: > On Tue, Jun 12, 2007 at 06:24:39PM +0200, Ulrich Weigand wrote: > > Hmmm. One thing I liked about the approach in my patch was that > > it in effect made *all* types gdbarch-specific. This would have > > allowed in the end to implement something like a get_type_arch () > > routine, which could be quite useful to push references to > > current_gdbarch out of the symbol parts of the debugger (where > > we often do not have a local gdbarch / frame / regcache argument, > > but where we typically operate on types or values). > > That seems to me like a bad idea. We do not know the gdbarch when we > read in the symbol file. All references to the current architecture > in the symbol readers are bogus - basically, they only work as long as > the things referenced are the same between any other architectures we > select. Like pointer size, for instance. Fortunately the file > usually contains sufficient information for that purpose. So are you suggesting that all references to gdbarch in the symbol readers ought to be removed? I'm not sure this is feasible, there are in fact a number of gdbarch callbacks that specifically provide information only to the symbol parts of GDB (like dwarf2_reg_to_regnum, or something like skip_prologue). What I had been thinking of is to explicitly assign a gdbarch to each objfile (probably as an objfile->arch member). Now this arch is -as you mention- not necessarily the same as the "current" architecture (what will become the per-thread / per-frame architecture), but it will simply be the gdbarch selected by the sniffers on the basis of the objfile (bfd) alone. This arch would then be used to provide per-platform configuration information to the symbol parts of GDB. Bye, Ulrich -- Dr. Ulrich Weigand GNU Toolchain for Linux on System z and Cell BE Ulrich.Weigand@de.ibm.com