From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 10910 invoked by alias); 12 Jun 2007 16:32:11 -0000 Received: (qmail 10892 invoked by uid 22791); 12 Jun 2007 16:32:09 -0000 X-Spam-Check-By: sourceware.org Received: from NaN.false.org (HELO nan.false.org) (208.75.86.248) by sourceware.org (qpsmtpd/0.31) with ESMTP; Tue, 12 Jun 2007 16:32:06 +0000 Received: from nan.false.org (localhost [127.0.0.1]) by nan.false.org (Postfix) with ESMTP id 6EB6A982DE; Tue, 12 Jun 2007 16:32:03 +0000 (GMT) Received: from caradoc.them.org (22.svnf5.xdsl.nauticom.net [209.195.183.55]) by nan.false.org (Postfix) with ESMTP id 2C4EC982DC; Tue, 12 Jun 2007 16:32:02 +0000 (GMT) Received: from drow by caradoc.them.org with local (Exim 4.67) (envelope-from ) id 1Hy9I1-0001mG-FL; Tue, 12 Jun 2007 12:32:17 -0400 Date: Tue, 12 Jun 2007 16:32:00 -0000 From: Daniel Jacobowitz To: Ulrich Weigand Cc: gdb-patches@sourceware.org Subject: Re: [5/10] Add "explicit size" types to builtin_type Message-ID: <20070612163217.GA6815@caradoc.them.org> Mail-Followup-To: Ulrich Weigand , gdb-patches@sourceware.org References: <20070612152235.GC16068@caradoc.them.org> <200706121624.l5CGOd9q019856@d12av02.megacenter.de.ibm.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200706121624.l5CGOd9q019856@d12av02.megacenter.de.ibm.com> User-Agent: Mutt/1.5.15 (2007-04-09) 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: 2007-06/txt/msg00198.txt.bz2 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. -- Daniel Jacobowitz CodeSourcery