This is the mail archive of the
gdb@sourceware.org
mailing list for the GDB project.
PowerPC SecurePLT - stepping into library function
- From: Michael Eager <eager at eagerm dot com>
- To: gdb at sourceware dot org
- Cc: Alan Modra <amodra at gmail dot com>
- Date: Fri, 06 Jan 2012 11:54:01 -0800
- Subject: PowerPC SecurePLT - stepping into library function
GDB doesn't step into functions in a shared library
on PowerPC which are compiled with -msecure-PLT. It steps
over the function like the "next" command.
It looks like GDB makes a number of assumptions based
on the original SVR4 PLT design and which are not valid
with securePLT. One assumption is that the PLT stub is
in the .plt section. Another is that the symbol for the
PLT stub will have an STT_ENTRY in the symtab.
It seems that the best way to fix this would be to create
a new OSABI sniffer for SecurePLT which identifies that
the executable was compiled with -msecurePLT. One issue
is how to identify these programs. The Power Arch 32-bit ABI
(Sect 5.2.5.2, note at end) says that these will have
R_PPC_REL16 relocations. I don't see any of these relocs.
The .plt section is marked ALLOC CODE WRITE in non-SecurePLT
and ALLOC WRITE in SecurePLT. Is the ABI incorrect or is
Binutils not following it?
Is there any possibility of a chimera: an executable compiled
using Secure PLT linking to libraries which use the old style
PLT? Or vice-versa? I'm assuming that this cannot happen.
I can modify BFD to record whether the .plt section in the
executable was marked CODE or not, create an new OSABI sniffer
to identify a new GDB_OSABI_LINUX_SECUREPLT ABI variant, and
then write the variants of find_solib_trampoline_target(), etc.,
which are needed to recognize the PLT stubs and glink code.
I'm open to suggestions about a different approach. Is there
something which I may have overlooked?
--
Michael Eager eager@eagercon.com
1960 Park Blvd., Palo Alto, CA 94306 650-325-8077