From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 24952 invoked by alias); 31 Oct 2007 02:09:04 -0000 Received: (qmail 24943 invoked by uid 22791); 31 Oct 2007 02:09:03 -0000 X-Spam-Check-By: sourceware.org Received: from NaN.false.org (HELO nan.false.org) (208.75.86.248) by sourceware.org (qpsmtpd/0.31) with ESMTP; Wed, 31 Oct 2007 02:08:59 +0000 Received: from nan.false.org (localhost [127.0.0.1]) by nan.false.org (Postfix) with ESMTP id 71938981F1; Wed, 31 Oct 2007 02:08:57 +0000 (GMT) Received: from caradoc.them.org (22.svnf5.xdsl.nauticom.net [209.195.183.55]) by nan.false.org (Postfix) with ESMTP id 50241980A5; Wed, 31 Oct 2007 02:08:57 +0000 (GMT) Received: from drow by caradoc.them.org with local (Exim 4.68) (envelope-from ) id 1In30q-0007vk-7Z; Tue, 30 Oct 2007 22:08:56 -0400 Date: Wed, 31 Oct 2007 03:17:00 -0000 From: Daniel Jacobowitz To: Ulrich Weigand Cc: gdb-patches@sourceware.org Subject: Re: [rfc] Fix mst_solib_trampoline symbol sections for PLT stubs Message-ID: <20071031020856.GA30157@caradoc.them.org> Mail-Followup-To: Ulrich Weigand , gdb-patches@sourceware.org References: <200710310136.l9V1adrr000915@d12av02.megacenter.de.ibm.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200710310136.l9V1adrr000915@d12av02.megacenter.de.ibm.com> User-Agent: Mutt/1.5.15 (2007-04-09) X-IsSubscribed: yes 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: 2007-10/txt/msg00841.txt.bz2 On Wed, Oct 31, 2007 at 02:36:39AM +0100, Ulrich Weigand wrote: > Hello, > > we're still seeing problems on ppc when stepping over shared library > function calls, due to the issue previously discussed e.g. in: > http://sourceware.org/ml/gdb-patches/2006-06/msg00368.html > > Now, at the time the discussion primarily focussed on ways how to > identify PLT stubs via e.g. code reading or BFD synthetic symbols. Which are otherwise useful too; I really recommend making a synthetic symtab. I thought PowerPC BFD already did... oh, 64-bit only. Right. > Now, for undefined symbols, the "value" is generally meaningless. > However, in this specific case, the linker actually may place a > significant piece of information into the value field: the address > of the PLT stub used to call the imported function. > > It is my understanding that this information is generally reliable, > as it is implemented e.g. to determine the value of a function > pointer constant refering to that symbol (due to the special ABI > rule that the "address" of a function imported into the main > executable, for function pointer comparison purpuses, is the > address of the PLT stub in the main executable). Yes. But if the address of the function is not taken somewhere in the executable, then the address of the undefined symbol will generally be left at zero. That should be true most of the time. So while I don't see anything wrong with your approach here, I'm surprised it fixed the testsuite failures; why do they have non-zero addresses? If we're taking their addresses in all cases, we need some new tests. The patch itself looks fine. -- Daniel Jacobowitz CodeSourcery