From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 55875 invoked by alias); 27 Aug 2015 14:03:05 -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 55860 invoked by uid 89); 27 Aug 2015 14:03:05 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.9 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; Thu, 27 Aug 2015 14:02:55 +0000 Received: from /spool/local by e06smtp13.uk.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Thu, 27 Aug 2015 15:02:34 +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; Thu, 27 Aug 2015 15:02:17 +0100 X-MailFrom: uweigand@de.ibm.com X-RcptTo: gdb-patches@sourceware.org Received: from b06cxnps3074.portsmouth.uk.ibm.com (d06relay09.portsmouth.uk.ibm.com [9.149.109.194]) by d06dlp02.portsmouth.uk.ibm.com (Postfix) with ESMTP id 5B1F92190075 for ; Thu, 27 Aug 2015 15:01:45 +0100 (BST) Received: from d06av10.portsmouth.uk.ibm.com (d06av10.portsmouth.uk.ibm.com [9.149.37.251]) by b06cxnps3074.portsmouth.uk.ibm.com (8.14.9/8.14.9/NCO v10.0) with ESMTP id t7RE29AX20250824 for ; Thu, 27 Aug 2015 14:02:12 GMT Received: from d06av10.portsmouth.uk.ibm.com (localhost [127.0.0.1]) by d06av10.portsmouth.uk.ibm.com (8.14.4/8.14.4/NCO v10.0 AVout) with ESMTP id t7RE1oQC021013 for ; Thu, 27 Aug 2015 08:01:51 -0600 Received: from oc7340732750.ibm.com (dyn-9-152-213-24.boeblingen.de.ibm.com [9.152.213.24]) by d06av10.portsmouth.uk.ibm.com (8.14.4/8.14.4/NCO v10.0 AVin) with ESMTP id t7RE1okh020710; Thu, 27 Aug 2015 08:01:50 -0600 Received: by oc7340732750.ibm.com (Postfix, from userid 500) id A727539FA; Thu, 27 Aug 2015 16:01:41 +0200 (CEST) Subject: Cell multi-arch symbol lookup broken (Re: [PATCH] solib_global_lookup: Fetch arch from objfile.) To: xdje42@gmail.com (Doug Evans) Date: Thu, 27 Aug 2015 14:03:00 -0000 From: "Ulrich Weigand" Cc: gdb-patches@sourceware.org In-Reply-To: from "Doug Evans" at Oct 31, 2014 07:27:09 PM MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <20150827140141.A727539FA@oc7340732750.ibm.com> X-TM-AS-MML: disable X-Content-Scanned: Fidelis XPS MAILER x-cbid: 15082714-0013-0000-0000-0000052C3F63 X-SW-Source: 2015-08/txt/msg00789.txt.bz2 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? Bye, Ulrich -- Dr. Ulrich Weigand GNU/Linux compilers and toolchain Ulrich.Weigand@de.ibm.com