From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 24507 invoked by alias); 18 Aug 2008 11:34:08 -0000 Received: (qmail 24498 invoked by uid 22791); 18 Aug 2008 11:34:07 -0000 X-Spam-Check-By: sourceware.org Received: from rock.gnat.com (HELO rock.gnat.com) (205.232.38.15) by sourceware.org (qpsmtpd/0.31) with ESMTP; Mon, 18 Aug 2008 11:33:33 +0000 Received: from localhost (localhost.localdomain [127.0.0.1]) by filtered-rock.gnat.com (Postfix) with ESMTP id 5A1062A960D; Mon, 18 Aug 2008 07:33:31 -0400 (EDT) Received: from rock.gnat.com ([127.0.0.1]) by localhost (rock.gnat.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id x5de0aaJpssJ; Mon, 18 Aug 2008 07:33:31 -0400 (EDT) Received: from joel.gnat.com (localhost.localdomain [127.0.0.1]) by rock.gnat.com (Postfix) with ESMTP id 9127A2A9605; Mon, 18 Aug 2008 07:33:30 -0400 (EDT) Received: by joel.gnat.com (Postfix, from userid 1000) id 6CA11E7ACD; Mon, 18 Aug 2008 13:33:23 +0200 (CEST) Date: Mon, 18 Aug 2008 11:34:00 -0000 From: Joel Brobecker To: Ulrich Weigand Cc: gdb-patches@sourceware.org Subject: Re: [rfc] Introduce "target_gdbarch" variable Message-ID: <20080818113323.GF16894@adacore.com> References: <200808131952.m7DJqVoN009120@d12av02.megacenter.de.ibm.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200808131952.m7DJqVoN009120@d12av02.megacenter.de.ibm.com> User-Agent: Mutt/1.4.2.2i 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-08/txt/msg00470.txt.bz2 Just my 2 cents... > The idea is that this variable would stay even as other uses of > current_gdbarch are being eliminated in favor of per-thread etc. > architectures. I am wondering why these ones are OK to stay, or perhaps you were thinking of a short-to-medium term situation. Otherwise, isn't this global going to be a problem with true multi-arch? Another situation where this might be a problem is when the debugger is debugging more than one process from different architectures (Stan's project). > - Giving these uses a different name makes it more obvious that the > remaining uses of current_gdbarch should be eliminated while these > can stay. That's a good reason. In fact, I started with something similar when I first worked on the project of getting rid of the "current_language" global (which I haven't forgotten about!) > Does this seem reasonable? It seems reasonable to me, modulo the part where I don't understand why the current globals used in target-remote/solib are OK to stay. -- Joel