This is the mail archive of the gdb@sourceware.org mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]