From: Michael Eager <eager@eagerm.com>
To: gdb@sourceware.org
Cc: Alan Modra <amodra@gmail.com>
Subject: PowerPC SecurePLT - stepping into library function
Date: Fri, 06 Jan 2012 19:54:00 -0000 [thread overview]
Message-ID: <4F075159.5090508@eagerm.com> (raw)
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
next reply other threads:[~2012-01-06 19:54 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-01-06 19:54 Michael Eager [this message]
2012-01-06 20:09 ` Joseph S. Myers
2012-01-06 20:27 ` Michael Eager
2012-01-06 20:15 ` Mark Kettenis
2012-01-06 20:24 ` Michael Eager
2012-01-06 20:56 ` Mark Kettenis
2012-01-07 20:57 ` Michael Eager
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4F075159.5090508@eagerm.com \
--to=eager@eagerm.com \
--cc=amodra@gmail.com \
--cc=gdb@sourceware.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).