From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 88301 invoked by alias); 28 Aug 2015 05:33:51 -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 88280 invoked by uid 89); 28 Aug 2015 05:33:49 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.8 required=5.0 tests=AWL,BAYES_00,FREEMAIL_ENVFROM_END_DIGIT,FREEMAIL_FROM,RCVD_IN_DNSWL_LOW,SPF_PASS autolearn=ham version=3.3.2 X-HELO: mail-pa0-f46.google.com Received: from mail-pa0-f46.google.com (HELO mail-pa0-f46.google.com) (209.85.220.46) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES128-GCM-SHA256 encrypted) ESMTPS; Fri, 28 Aug 2015 05:33:48 +0000 Received: by padfo6 with SMTP id fo6so11807509pad.0 for ; Thu, 27 Aug 2015 22:33:46 -0700 (PDT) X-Received: by 10.66.122.207 with SMTP id lu15mr12219967pab.146.1440740026192; Thu, 27 Aug 2015 22:33:46 -0700 (PDT) Received: from seba.sebabeach.org.gmail.com (173-13-178-53-sfba.hfc.comcastbusiness.net. [173.13.178.53]) by smtp.gmail.com with ESMTPSA id nm8sm4291270pbc.20.2015.08.27.22.33.45 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 27 Aug 2015 22:33:45 -0700 (PDT) From: Doug Evans To: "Ulrich Weigand" Cc: gdb-patches@sourceware.org Subject: Re: Cell multi-arch symbol lookup broken (Re: [PATCH] solib_global_lookup: Fetch arch from objfile.) References: <20150827140141.A727539FA@oc7340732750.ibm.com> Date: Fri, 28 Aug 2015 05:33:00 -0000 In-Reply-To: <20150827140141.A727539FA@oc7340732750.ibm.com> (Ulrich Weigand's message of "Thu, 27 Aug 2015 16:01:41 +0200 (CEST)") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.5 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-IsSubscribed: yes X-SW-Source: 2015-08/txt/msg00811.txt.bz2 "Ulrich Weigand" writes: > Doug Evans wrote: > >> solib_global_lookup should be using the objfile's arch, >> not fetching it from global state. >> >> Regression tested on amd64-linux. >> >> 2014-10-31 Doug Evans >> >> * objfiles.c (get_objfile_arch): Constify. >> * objfiles.h (get_objfile_arch): Update prototype. >> * solib.c (solib_global_lookup): Fetch arch from objfile, >> not target_gdbarch. > > This also causes a regression in Cell multi-arch debugging. > > The problem is that solib_ops are really only installed for > the main target_gdbarch. As opposed to many other things, > there is just a single solib_ops vector, intended to describe > the dynamic loader in use on the inferior. While it can make > sense to have multiple loaders when debugging different > inferiors, within a single inferior we support only one. > > The solib_global_lookup routine was intended to describe the > operation of that (single) dynamic loader, so that GDB's symbol > lookup can achieve the same result as the native dynamic loader > would. That's why we added that routine to the solib_ops. > > On Cell, the dynamic loader runs on the PowerPC side (which > is was target_gdbarch () returns), and so we installed the > solib_ops there. The Cell implementation of solib_global_lookup > then handles both PowerPC and SPU objects. > > However, after your patch, this implementation now never gets > called for SPU objects any more, which means the special > lookup rules are no longer implemented. > > Simply reverting this patch makes everything work for me again. > Was there any specific reason why you made this change in the > first place? Does this fix any specific problem? Interesting. I wasn't aware of this treatment of gdbarch. Sounds like another API cleanup is in order, it's pretty subtle. 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.] 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.