public inbox for gdb@sourceware.org
 help / color / mirror / Atom feed
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

             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).