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