From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 19096 invoked by alias); 7 Nov 2007 15:05:20 -0000 Received: (qmail 18905 invoked by uid 22791); 7 Nov 2007 15:05:01 -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; Wed, 07 Nov 2007 15:04:59 +0000 Received: from nan.false.org (localhost [127.0.0.1]) by nan.false.org (Postfix) with ESMTP id EF62998353; Wed, 7 Nov 2007 15:04:57 +0000 (GMT) Received: from caradoc.them.org (22.svnf5.xdsl.nauticom.net [209.195.183.55]) by nan.false.org (Postfix) with ESMTP id D540B9833F; Wed, 7 Nov 2007 15:04:57 +0000 (GMT) Received: from drow by caradoc.them.org with local (Exim 4.68) (envelope-from ) id 1IpmSf-0005QN-54; Wed, 07 Nov 2007 10:04:57 -0500 Date: Wed, 07 Nov 2007 15:05:00 -0000 From: Daniel Jacobowitz To: Markus Deuling Cc: GDB Patches , Ulrich Weigand Subject: Re: [rfc] [01/05] Get rid of current_gdbarch in gdbarch.{c,h,sh} Message-ID: <20071107150457.GA20821@caradoc.them.org> Mail-Followup-To: Markus Deuling , GDB Patches , Ulrich Weigand References: <47319D44.2060802@de.ibm.com> <20071107125925.GB14179@caradoc.them.org> <4731D20A.7020506@de.ibm.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4731D20A.7020506@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-11/txt/msg00130.txt.bz2 On Wed, Nov 07, 2007 at 03:56:10PM +0100, Markus Deuling wrote: > Daniel Jacobowitz schrieb: > > On Wed, Nov 07, 2007 at 12:11:00PM +0100, Markus Deuling wrote: > >> architecture. This ensures that the new architectures initial > >> values are not influenced by the previous architecture. Once > >> everything is parameterised with gdbarch, this will go away. */ > >> - struct gdbarch *current_gdbarch; > >> + struct gdbarch *gdbarch; > > Please read the comment above this variable :-) > > Hm, > will gdbarch_alloc go away? I thought every target uses gdbarch_alloc to > allocate a basic > gdbarch structure and then it overwrites every necessary callback to fit to its > architecture. /* NOTE: The new architecture variable is named \`\`current_gdbarch'' so that macros such as TARGET_ARCHITECTURE, when expanded, refer to the current local architecture and not the previous global architecture. This ensures that the new architectures initial values are not influenced by the previous architecture. Once everything is parameterised with gdbarch, this will go away. */ struct gdbarch *current_gdbarch; "this will go away" refers to "is named current_gdbarch". -- Daniel Jacobowitz CodeSourcery