From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 23626 invoked by alias); 18 Aug 2008 13:59:04 -0000 Received: (qmail 23614 invoked by uid 22791); 18 Aug 2008 13:59:02 -0000 X-Spam-Check-By: sourceware.org Received: from mtagate7.de.ibm.com (HELO mtagate7.de.ibm.com) (195.212.29.156) by sourceware.org (qpsmtpd/0.31) with ESMTP; Mon, 18 Aug 2008 13:58:03 +0000 Received: from d12nrmr1607.megacenter.de.ibm.com (d12nrmr1607.megacenter.de.ibm.com [9.149.167.49]) by mtagate7.de.ibm.com (8.13.8/8.13.8) with ESMTP id m7IDvDsB636146 for ; Mon, 18 Aug 2008 13:57:13 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.0) with ESMTP id m7IDvDCt4100230 for ; Mon, 18 Aug 2008 15:57:13 +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 m7IDvDvh002742 for ; Mon, 18 Aug 2008 15:57:13 +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 m7IDvCiv002739; Mon, 18 Aug 2008 15:57:12 +0200 Message-Id: <200808181357.m7IDvCiv002739@d12av02.megacenter.de.ibm.com> Received: by tuxmaker.boeblingen.de.ibm.com (sSMTP sendmail emulation); Mon, 18 Aug 2008 15:57:12 +0200 Subject: Re: [rfc] Introduce "target_gdbarch" variable To: brobecker@adacore.com (Joel Brobecker) Date: Mon, 18 Aug 2008 13:59:00 -0000 From: "Ulrich Weigand" Cc: gdb-patches@sourceware.org In-Reply-To: <20080818113323.GF16894@adacore.com> from "Joel Brobecker" at Aug 18, 2008 03:33:23 PM 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-08/txt/msg00482.txt.bz2 Joel Brobecker wrote: > Just my 2 cents... Thanks for looking at this! > > 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). The idea was that target_gdbarch is the architecture assoicated with the connection to one target. As we currently support only one target at a time, using a global for that should be fine. As soon as we start supporting multiple target connections at the same time, we'd need multiple instances of this as well. At this point, it would probably make sense to make this a member of "struct target". > > 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. "remote" uses gdbarch to store properties of the connection to its targets. For example, the layout of the "g" packet is stored there. Even in a scenario where we have per-thread / per-frame architectures, those properties will still stay invariant for one target. Similarly, "solib" stores the overall method to use to search for shared libraries as gdbarch properties. Again, this is a global property of a certain target, even though the inferior may have some threads / frames that use a different architecture. It may be that at some point, this will need to be fundamentally changed anyway, e.g. because the association of one single solib method to one target may no longer be sufficient. At this point, those properties might have to be moved out of gdbarch completely. But even so, I think moving them to target_gdbarch (even if in the long run this turns out to be just a temporary solution) would be helpful in the short run, as it allows adding per-frame architecture support without major up-front changes to the solib code ... Bye, Ulrich -- Dr. Ulrich Weigand GNU Toolchain for Linux on System z and Cell BE Ulrich.Weigand@de.ibm.com