From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 10280 invoked by alias); 12 May 2006 22:42:49 -0000 Received: (qmail 10270 invoked by uid 22791); 12 May 2006 22:42:48 -0000 X-Spam-Check-By: sourceware.org Received: from e32.co.us.ibm.com (HELO e32.co.us.ibm.com) (32.97.110.150) by sourceware.org (qpsmtpd/0.31) with ESMTP; Fri, 12 May 2006 22:42:45 +0000 Received: from d03relay04.boulder.ibm.com (d03relay04.boulder.ibm.com [9.17.195.106]) by e32.co.us.ibm.com (8.12.11.20060308/8.12.11) with ESMTP id k4CMgikS015060 for ; Fri, 12 May 2006 18:42:44 -0400 Received: from d03av02.boulder.ibm.com (d03av02.boulder.ibm.com [9.17.195.168]) by d03relay04.boulder.ibm.com (8.12.10/NCO/VER6.8) with ESMTP id k4CMghM9192408 for ; Fri, 12 May 2006 16:42:43 -0600 Received: from d03av02.boulder.ibm.com (loopback [127.0.0.1]) by d03av02.boulder.ibm.com (8.12.11/8.13.3) with ESMTP id k4CMghdO032562 for ; Fri, 12 May 2006 16:42:43 -0600 Received: from dufur.beaverton.ibm.com (dufur.beaverton.ibm.com [9.47.22.20]) by d03av02.boulder.ibm.com (8.12.11/8.12.11) with ESMTP id k4CMghvF032517 for ; Fri, 12 May 2006 16:42:43 -0600 Subject: [patch] Strange stepping behaviour with ppc32 with secure PLTs From: PAUL GILLIAM Reply-To: pgilliam@us.ibm.com To: gdb-patches@sources.redhat.com Content-Type: multipart/mixed; boundary="=-tz/Vt8LbxP9raCOlqCAt" Date: Fri, 12 May 2006 22:50:00 -0000 Message-Id: <1147469935.3672.114.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-05/txt/msg00271.txt.bz2 --=-tz/Vt8LbxP9raCOlqCAt Content-Type: text/plain Content-Transfer-Encoding: 7bit Content-length: 2268 These hacks, er, I mean 'patches', fix 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. They implement the two 'GDB only solutions' 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 To answer Danial's questions: >> I would rather have a GDB only solution. > > Why? I am not familiar enough with BFD to implement symbols is a reasonable time. > What do you mean by "unknown section"? This is what I mean: (top-gdb) p *bfd_section $2 = {name = 0x1049c528 "*UND*", id = 1, index = 0, ... I have attached two patches: fix1.diff and fix2.diff. Fix1.diff implements the first 'GDB only' solution and seems to be the best of the two. Here are the testsuite results on a system with secure PLT's: Before: # of expected passes 10749 # of unexpected failures 316 # of expected failures 41 # of known failures 63 # of unresolved testcases 12 # of untested testcases 4 # of unsupported tests 10 After: # of expected passes 10969 # of unexpected failures 107 # of expected failures 42 # of known failures 64 # of untested testcases 5 # of unsupported tests 10 I also obtained before and after testsuite results on an x86 system and there was no change. Fix2.diff implements the second GDB only approach and while the testsuite results show that it is better than no fix, it is not quite as good as fix1.diff. Here are the testsuite results for fix2.diff: After: # of expected passes 10966 # of unexpected failures 109 # of expected failures 42 # of known failures 64 # of unresolved testcases 1 # of untested testcases 5 # of unsupported tests 10 Again, there was not change with the x86 testsuite results. Are either of these OK to commit? -=# Paul #=- --=-tz/Vt8LbxP9raCOlqCAt Content-Disposition: attachment; filename=fix1.diff Content-Type: text/x-patch; name=fix1.diff; charset=UTF-8 Content-Transfer-Encoding: 7bit Content-length: 961 2006-05-12 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 12 May 2006 22:17:06 -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 ignore symbols for solib trampolines */ + && MSYMBOL_TYPE (&msymbol[hi]) != mst_solib_trampoline && SYMBOL_BFD_SECTION (&msymbol[hi]) != section) --hi; --=-tz/Vt8LbxP9raCOlqCAt Content-Disposition: attachment; filename=fix2.diff Content-Type: text/x-patch; name=fix2.diff; charset=UTF-8 Content-Transfer-Encoding: 7bit Content-length: 1140 2006-05-12 Paul Gilliam * minsyms.c (prim_record_minimal_symbol_and_info): Set a new minimal symbol's section to '.text', and zero out it's bfd-section, if the symbol is for solib-trampoline code. 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 12 May 2006 16:48:54 -0000 @@ -619,9 +619,18 @@ SYMBOL_SET_NAMES (msymbol, (char *)name, strlen (name), objfile); SYMBOL_VALUE_ADDRESS (msymbol) = address; - SYMBOL_SECTION (msymbol) = section; - SYMBOL_BFD_SECTION (msymbol) = bfd_section; + if (ms_type != mst_solib_trampoline) + { + SYMBOL_SECTION (msymbol) = section; + SYMBOL_BFD_SECTION (msymbol) = bfd_section; + } + else + { + SYMBOL_SECTION (msymbol) = SECT_OFF_TEXT (objfile); + SYMBOL_BFD_SECTION (msymbol) = 0; + } + MSYMBOL_TYPE (msymbol) = ms_type; /* FIXME: This info, if it remains, needs its own field. */ MSYMBOL_INFO (msymbol) = info; /* FIXME! */ --=-tz/Vt8LbxP9raCOlqCAt--