From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 27092 invoked by alias); 11 Jun 2007 17:53:54 -0000 Received: (qmail 27082 invoked by uid 22791); 11 Jun 2007 17:53:54 -0000 X-Spam-Check-By: sourceware.org Received: from mail.codesourcery.com (HELO mail.codesourcery.com) (65.74.133.4) by sourceware.org (qpsmtpd/0.31) with ESMTP; Mon, 11 Jun 2007 17:53:51 +0000 Received: (qmail 31940 invoked from network); 11 Jun 2007 17:53:50 -0000 Received: from unknown (HELO localhost) (jimb@127.0.0.2) by mail.codesourcery.com with ESMTPA; 11 Jun 2007 17:53:50 -0000 To: "Ulrich Weigand" Cc: gdb-patches@sourceware.org Subject: Re: [0/10] Clean up built-in types References: <200706082313.l58NDw6M016230@d12av02.megacenter.de.ibm.com> From: Jim Blandy Date: Mon, 11 Jun 2007 17:53:00 -0000 In-Reply-To: <200706082313.l58NDw6M016230@d12av02.megacenter.de.ibm.com> (Ulrich Weigand's message of "Sat, 9 Jun 2007 01:13:58 +0200 (CEST)") Message-ID: User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii 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/msg00150.txt.bz2 "Ulrich Weigand" writes: > most of the remaining gdbarch-swapped data items are built-in data types. > > The following patch set reworks the handling of these types and gets rid > of the need to swap variables. > > The basic idea is to replace all global variables like builtin_type_void > with a "compatibility macro" referencing the current architecture's > builtin_type structure: > > #define builtin_type_void \ > (builtin_type (current_gdbarch)->builtin_void) > > To make this possible, we need to ensure that: > > - the builtin types are never used in a context where the macro version > would break (e.g. taking the address of a builtin type) > > - all builtin types are in fact represented in the builtin_type > per-gdbarch data structure as well > > In the future, those compatibility macros can be replaced by directly > using builtin_type on the appropriate gdbarch at the call site. At first I was concerned that builtin_type (current_gdbarch) would be populated too late to be useful, but looking at the code I saw that referring to builtin_type_ from a gdbarch_init function has always been broken. The M32C port creates a bunch of types in its gdbarch_init function, constructing its own 'void', 'void *', and 'void (*)()' types to avoid referring to the builtin_type_ variables. Do you see anything offhand in m32c-tdep.c:make_types (which is called from m32c_gdbarch_init) that would be incompatible with this approach?