From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 12492 invoked by alias); 7 Sep 2008 15:59:27 -0000 Received: (qmail 12484 invoked by uid 22791); 7 Sep 2008 15:59:26 -0000 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.31) with ESMTP; Sun, 07 Sep 2008 15:58:34 +0000 Received: from d12nrmr1607.megacenter.de.ibm.com (d12nrmr1607.megacenter.de.ibm.com [9.149.167.49]) by mtagate3.de.ibm.com (8.13.8/8.13.8) with ESMTP id m87FwLGc038110 for ; Sun, 7 Sep 2008 15:58:21 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.1) with ESMTP id m87FwKgp4321376 for ; Sun, 7 Sep 2008 17:58:20 +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 m87FwKPt005934 for ; Sun, 7 Sep 2008 17:58:20 +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 m87FwKiG005931; Sun, 7 Sep 2008 17:58:20 +0200 Message-Id: <200809071558.m87FwKiG005931@d12av02.megacenter.de.ibm.com> Received: by tuxmaker.boeblingen.de.ibm.com (sSMTP sendmail emulation); Sun, 7 Sep 2008 17:58:20 +0200 Subject: Re: [rfc][21/37] Eliminate builtin_type_ macros: Platform-neutral builtin_type_void To: drow@false.org (Daniel Jacobowitz) Date: Sun, 07 Sep 2008 15:59:00 -0000 From: "Ulrich Weigand" Cc: brobecker@adacore.com (Joel Brobecker), gdb-patches@sourceware.org In-Reply-To: <20080906041154.GA10692@caradoc.them.org> from "Daniel Jacobowitz" at Sep 06, 2008 12:11:54 AM 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: 2008-09/txt/msg00130.txt.bz2 Daniel Jacobowitz wrote: > On Fri, Sep 05, 2008 at 05:37:24PM -0700, Joel Brobecker wrote: > > I don't want to add a field in our type structure to mark the types > > that are architecture-specific, since that would have a noticeable > > memory cost just for a few specific types. > > No, it wouldn't. We have tons of free flag bits; it sounds like the > right thing to do would be to mark only the global types. We could do that, but I'm not sure this really helps with the underlying core problem. The problem isn't so much calling lookup_pointer_type on a platform-neutral type, the actual problem is: - make_pointer_type using current_gdbarch to determine pointer size - the *single* cached pointer type in TYPE_POINTER_TYPE I can see two ways forward to solve those problems: 1.) lookup_pointer_type creates a pointer type of the same architecture as the underlying type This would imply calling lookup_pointer_type on a platform-neutral type would be invalid, but a simple flag is not enough, because for platform-specific types we have to be able to actually get at the gdbarch itself. So we'd have to have something like a get_type_arch (...) routine, and the platform-neutral check would be implemented by checking whether this routine returns NULL. 2.) lookup_pointer_type gets an gdbarch argument (or maybe just a "size" argument, as that is what we really need) In this case, we'd probably have to extend the caching mechanims to cache pointers of multiple different sizes (note that to some extent that exists today via TYPE_CHAIN, see make_qualified_type). Then, there wouldn't really be any strict reason any more why we couldn't allow making pointer types to platform-neutral types ... It seems to me that option 1.) might be preferable, however I don't really want to grow "struct type" to hold a gdbarch pointer. In most cases, we can use get_objfile_arch (TYPE_OBJFILE (...)) to get at the type's architecture, but there are some corner-cases where this doesn't work right now, e.g. the copy_type_recursive logic ... Any opinions on this? Bye, Ulrich -- Dr. Ulrich Weigand GNU Toolchain for Linux on System z and Cell BE Ulrich.Weigand@de.ibm.com