From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 127709 invoked by alias); 28 Aug 2015 13:38:49 -0000 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 Received: (qmail 127699 invoked by uid 89); 28 Aug 2015 13:38:48 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-3.0 required=5.0 tests=AWL,BAYES_00,RP_MATCHES_RCVD,SPF_PASS autolearn=ham version=3.3.2 X-HELO: e06smtp13.uk.ibm.com Received: from e06smtp13.uk.ibm.com (HELO e06smtp13.uk.ibm.com) (195.75.94.109) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (CAMELLIA256-SHA encrypted) ESMTPS; Fri, 28 Aug 2015 13:38:47 +0000 Received: from /spool/local by e06smtp13.uk.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Fri, 28 Aug 2015 14:38:44 +0100 Received: from d06dlp02.portsmouth.uk.ibm.com (9.149.20.14) by e06smtp13.uk.ibm.com (192.168.101.143) with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted; Fri, 28 Aug 2015 14:38:42 +0100 X-MailFrom: uweigand@de.ibm.com X-RcptTo: gdb-patches@sourceware.org Received: from b06cxnps4075.portsmouth.uk.ibm.com (d06relay12.portsmouth.uk.ibm.com [9.149.109.197]) by d06dlp02.portsmouth.uk.ibm.com (Postfix) with ESMTP id D980B2190056 for ; Fri, 28 Aug 2015 14:38:14 +0100 (BST) Received: from d06av03.portsmouth.uk.ibm.com (d06av03.portsmouth.uk.ibm.com [9.149.37.213]) by b06cxnps4075.portsmouth.uk.ibm.com (8.14.9/8.14.9/NCO v10.0) with ESMTP id t7SDccm334799756 for ; Fri, 28 Aug 2015 13:38:41 GMT Received: from d06av03.portsmouth.uk.ibm.com (localhost [127.0.0.1]) by d06av03.portsmouth.uk.ibm.com (8.14.4/8.14.4/NCO v10.0 AVout) with ESMTP id t7SDcTHx022669 for ; Fri, 28 Aug 2015 07:38:29 -0600 Received: from oc7340732750.ibm.com (icon-9-164-150-178.megacenter.de.ibm.com [9.164.150.178]) by d06av03.portsmouth.uk.ibm.com (8.14.4/8.14.4/NCO v10.0 AVin) with ESMTP id t7SDcSwL022475; Fri, 28 Aug 2015 07:38:29 -0600 Received: by oc7340732750.ibm.com (Postfix, from userid 500) id F0A1B8775; Fri, 28 Aug 2015 15:38:18 +0200 (CEST) Subject: Re: Cell multi-arch symbol lookup broken (Re: [PATCH] solib_global_lookup: Fetch arch from objfile.) To: xdje42@gmail.com (Doug Evans) Date: Fri, 28 Aug 2015 13:38:00 -0000 From: "Ulrich Weigand" Cc: gdb-patches@sourceware.org In-Reply-To: from "Doug Evans" at Aug 27, 2015 10:32:46 PM MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <20150828133818.F0A1B8775@oc7340732750.ibm.com> X-TM-AS-MML: disable X-Content-Scanned: Fidelis XPS MAILER x-cbid: 15082813-0013-0000-0000-0000052FEE58 X-SW-Source: 2015-08/txt/msg00814.txt.bz2 Doug Evans wrote: > So I get now that there is an inferior gdbarch that is potentially > distinct from whatever gdbarch one has at hand (e.g., an objfile's), > [that's the easy part] > and that certain API calls *have* to use the inferior gdbarch. > [that's the subtle part] > > One question that comes to mind is why don't the other gdbarches > in the system, e.g., the spu's, delegate these calls to its "parent" gdbarch? > Any design that requires global state like this is suboptimal, > and I'd like to see gdb move away from it wherever possible. > [Here we have a gdbarch from the objfile, but we can't use it.] > > Another thought that comes to mind is, if we don't want "child gdbarches" > to delegate to "parent gdbarches" (and I haven't decided myself), then > another way to go is to use different types. > E.g., inferior_gdbarch and gdbarch. > [I might name inferior_gdbarch differently, depending on what API calls > it contains, but this would be another way to avoid potential confusion > over what the correct gdbarch to use is in any particular situation.] Well, it's a bit more subtle, even. First of all, there's two distinct "classes" of gdbarch structures, corresponding to the "symbol side" and the "target side" of GDB, respectively. On the symbol side, we have all the information that is determined solely by looking at an objfile and well-known ABI conventions. On the target side, we have in addition all the information that is determined by the running target (e.g. register names etc.). For more details, see here: https://sourceware.org/ml/gdb-patches/2007-12/msg00142.html The "symbol side" gdbarch is used as the architecture associated with objfiles, types, and symbols. The "target side" gdbarch is used as the architecture associated with the inferior as a whole, with a thread, or with a stack frame. Now, in both symbol side and target side, there may be different architecture instances active during a single debug session. In particular, during Cell/B.E. debugging, there will be PowerPC objfiles and SPU objfiles. In addition, some threads and/or stack frames will be of PowerPC architecture, and others of SPU architecture. The main inferior will be of PowerPC architecture (in mixed debugging) or of SPU architecture (when doing SPU stand-alone debugging). (With multi-inferior debugging, we may have different main inferior architectures at the same time as well.) Now, I tend to agree that there should be some sort of child/parent relationship between a symbol-side gdbarch and a target-side gdbarch. Specifically, a target-side gdbarch should *contain* a symbol-side gdbarch *and additional information*. However, this should still apply only to the same basic architecture, i.e. the PowerPC target gdbarch should include the PowerPC symbol gdbarch, and likewise for SPU. [ I originally wanted to implement this as two distinct data types, but this will require a significant amount of refactoring work, and in the end I never got around to doing this. ] But I don't think there should be a direct relationship between the SPU arch and the PowerPC arch, as you describe above. Execution may be in a PowerPC frame on an SPU thread running in a PowerPC inferior ... but there's no relationship between the architectures as such. When using any of these, you just have to know whether you're interested in a property of the current frame, current thread, or current inferior. Now, the "target_gdbarch" is a bit of a special case. It used to have a distinct semantics: the architecture used at the target interface level. (Think of it as the architecture that defines the contents of the register packets of the remote gdbserver protocol.) However, since the remote protocol was extended to actually support using *multiple* different architectures, there's no longer a need for target_gdbarch as a distinct concept. And in fact, it's now simply defined as the architecture of the current inferior: struct gdbarch * target_gdbarch (void) { return current_inferior ()->gdbarch; } I'd be in favor of inlining this function into every user, and starting to replace "current_inferior" with any given inferior that we may be actually operating on in these places. > I'm ok with reverting this particular part of the patch, > though it'd be helpful to add a comment explaining > why things are the way they are. There is a comment in gdbarch.h, but that may not be in a prominent enough place: /* The architecture associated with the inferior through the connection to the target. The architecture vector provides some information that is really a property of the inferior, accessed through a particular target: ptrace operations; the layout of certain RSP packets; the solib_ops vector; etc. To differentiate architecture accesses to per-inferior/target properties from per-thread/per-frame/per-objfile properties, accesses to per-inferior/target properties should be made through this gdbarch. */ Maybe one way to make this obvious would be to change solib_ops to take an inferior instead of a gdbarch as argument ... Bye, Ulrich -- Dr. Ulrich Weigand GNU/Linux compilers and toolchain Ulrich.Weigand@de.ibm.com