[patch] Strange stepping behaviour with ppc32 with secure PLTs

[PAUL GILLIAM <pgilliam at us dot ibm dot com>]

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 <foo@stub> 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 #=-

2006-05-12  Paul Gilliam  <pgilliam@us.ibm.com>

	* 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;


2006-05-12  Paul Gilliam  <pgilliam@us.ibm.com>

	* 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! */