From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 15793 invoked by alias); 18 Aug 2008 14:11:58 -0000 Received: (qmail 15785 invoked by uid 22791); 18 Aug 2008 14:11:57 -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 14:11:16 +0000 Received: from localhost (localhost.localdomain [127.0.0.1]) by filtered-rock.gnat.com (Postfix) with ESMTP id DEAF72A9729; Mon, 18 Aug 2008 10:11:14 -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 9VsagHbXgbwm; Mon, 18 Aug 2008 10:11:14 -0400 (EDT) Received: from joel.gnat.com (localhost.localdomain [127.0.0.1]) by rock.gnat.com (Postfix) with ESMTP id 1CCCD2A969B; Mon, 18 Aug 2008 10:11:14 -0400 (EDT) Received: by joel.gnat.com (Postfix, from userid 1000) id 0366DE7ACD; Mon, 18 Aug 2008 16:11:07 +0200 (CEST) Date: Mon, 18 Aug 2008 14:11:00 -0000 From: Joel Brobecker To: Ulrich Weigand Cc: gdb-patches@sourceware.org Subject: Re: [rfc] Introduce "target_gdbarch" variable Message-ID: <20080818141106.GP16894@adacore.com> References: <20080818113323.GF16894@adacore.com> <200808181357.m7IDvCiv002739@d12av02.megacenter.de.ibm.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200808181357.m7IDvCiv002739@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/msg00483.txt.bz2 > "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. [...] > 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. I was thinking exactly this as I was reading your explaination! As struct target seems indeed the way to go, eventually. > 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 ... I agree it's helpful, and the cost of having to another global doesn't seem very high (at least at first sight! I won't be surprised if we run into trouble later because of some little detail we forgot, but I'm sure we can deal with them when they arise). I know others such as Daniel know this code a lot better than I do, though. It'd be nice if they could comment as well, but no objection from me. -- Joel