[patch] Strange stepping behaviour with ppc32 with secure PLTs

PAUL GILLIAM
2006-05-12T22:42:49Z

[-- Attachment #1: Type: text/plain, Size: 2268 bytes --]

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 #=-

[-- Attachment #2: fix1.diff --]
[-- Type: text/x-patch, Size: 961 bytes --]

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;

[-- Attachment #3: fix2.diff --]
[-- Type: text/x-patch, Size: 1140 bytes --]

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