From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 24788 invoked by alias); 23 Jun 2006 21:06:16 -0000 Received: (qmail 24780 invoked by uid 22791); 23 Jun 2006 21:06:15 -0000 X-Spam-Check-By: sourceware.org Received: from e2.ny.us.ibm.com (HELO e2.ny.us.ibm.com) (32.97.182.142) by sourceware.org (qpsmtpd/0.31) with ESMTP; Fri, 23 Jun 2006 21:06:08 +0000 Received: from d01relay02.pok.ibm.com (d01relay02.pok.ibm.com [9.56.227.234]) by e2.ny.us.ibm.com (8.12.11.20060308/8.12.11) with ESMTP id k5NL62AQ031371 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Fri, 23 Jun 2006 17:06:02 -0400 Received: from d01av04.pok.ibm.com (d01av04.pok.ibm.com [9.56.224.64]) by d01relay02.pok.ibm.com (8.13.6/NCO/VER7.0) with ESMTP id k5NL60Nv264476 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Fri, 23 Jun 2006 17:06:02 -0400 Received: from d01av04.pok.ibm.com (loopback [127.0.0.1]) by d01av04.pok.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id k5NL5xlL026171 for ; Fri, 23 Jun 2006 17:06:00 -0400 Received: from dufur.beaverton.ibm.com (dufur.beaverton.ibm.com [9.47.22.20]) by d01av04.pok.ibm.com (8.12.11.20060308/8.12.11) with ESMTP id k5NL5x86026146; Fri, 23 Jun 2006 17:05:59 -0400 Subject: Re: [patch] Strange stepping behaviour with ppc32 with secure PLTs From: PAUL GILLIAM Reply-To: pgilliam@us.ibm.com To: Alan Modra Cc: Mark Kettenis , gdb-patches@sources.redhat.com In-Reply-To: <20060520011451.GE22757@bubble.grove.modra.org> References: <1147469935.3672.114.camel@dufur.beaverton.ibm.com> <20060512225044.GA20706@nevyn.them.org> <20060513143141.GB19700@bubble.grove.modra.org> <20060513145829.GA3721@nevyn.them.org> <20060515005619.GC19700@bubble.grove.modra.org> <20060515150854.GA28766@nevyn.them.org> <20060515234620.GG19700@bubble.grove.modra.org> <200605160634.k4G6Y49p009983@elgar.sibelius.xs4all.nl> <20060516071833.GH19700@bubble.grove.modra.org> <1148055854.315.5.camel@dufur.beaverton.ibm.com> <20060520011451.GE22757@bubble.grove.modra.org> Content-Type: multipart/mixed; boundary="=-CcssanD4OXnqznKz9eyu" Date: Fri, 23 Jun 2006 21:06:00 -0000 Message-Id: <1151092884.7608.82.camel@dufur.beaverton.ibm.com> Mime-Version: 1.0 X-Mailer: Evolution 2.2.2 (2.2.2-5) X-IsSubscribed: yes Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org X-SW-Source: 2006-06/txt/msg00368.txt.bz2 --=-CcssanD4OXnqznKz9eyu Content-Type: text/plain Content-Transfer-Encoding: 7bit Content-length: 829 It's been more than a month, so I thought I'd try again. I also thought I'd try the new patch tracker: :ADDPATCH PowerPC-32: This patch fixes a problem gdb has 'next'ing over a call to a library function on a ppc32 target program when secure PLT's are being used. It implements a 'GDB only solution' of the previous discussion on the 'gdb@' mailing list. Here is that previous discussion: http://sourceware.org/ml/gdb/2006-05/msg00154.html and Daniel Jacobowitz's response: http://sourceware.org/ml/gdb/2006-05/msg00155.html Subsequent discussion on gdb-patches begins here: http://sourceware.org/ml/gdb-patches/2006-05/msg00270.html And peter out here: http://sourceware.org/ml/gdb-patches/2006-05/msg00420.html I have attached a update of the patch, now diff'ed against current sources. OK to commit? -=# Paul #=- --=-CcssanD4OXnqznKz9eyu Content-Disposition: attachment; filename=keep-solib-tramp-sym.diff Content-Type: text/x-patch; name=keep-solib-tramp-sym.diff; charset=utf-8 Content-Transfer-Encoding: 7bit Content-length: 867 2006-06-23 Paul Gilliam * minsyms.c (lookup_minimal_symbol_by_pc_section): Don't ignore minimal symbols for solib trampolines just because they're in a different section than the PC. Index: minsyms.c =================================================================== RCS file: /cvs/src/src/gdb/minsyms.c,v retrieving revision 1.45 diff -a -u -r1.45 minsyms.c --- minsyms.c 17 Dec 2005 22:34:01 -0000 1.45 +++ minsyms.c 23 Jun 2006 20:59:34 -0000 @@ -486,6 +486,8 @@ don't fill the bfd_section member, so don't throw away symbols on those platforms. */ && SYMBOL_BFD_SECTION (&msymbol[hi]) != NULL + /* Don't ignoe symbols for solib tranpolines. */ + && MSYMBOL_TYPE (&msymbol[hi]) != mst_solib_trampoline && SYMBOL_BFD_SECTION (&msymbol[hi]) != section) --hi; --=-CcssanD4OXnqznKz9eyu--