From: Daniel Jacobowitz <drow@false.org>
To: Alan Modra <amodra@bigpond.net.au>
Cc: PAUL GILLIAM <pgilliam@us.ibm.com>, gdb-patches@sources.redhat.com
Subject: Re: [patch] Strange stepping behaviour with ppc32 with secure PLTs
Date: Sat, 13 May 2006 15:13:00 -0000 [thread overview]
Message-ID: <20060513145829.GA3721@nevyn.them.org> (raw)
In-Reply-To: <20060513143141.GB19700@bubble.grove.modra.org>
On Sun, May 14, 2006 at 12:01:41AM +0930, Alan Modra wrote:
> Not too hard, but messy. The only real difficulty is finding the stubs.
> We don't have any handy symbols or relocs to identify them, so that
> means code reading.
>
> We do have --emit-stub-syms to emit symbols on stubs at link time. I
> probably should have made the linker always emit the first stub sym so
> we could easily find all the stubs.
Hmm. Do they still end up in a section named .plt? That'd probably
make it easier for both gdb and binutils.
> > The right thing to do then is probably to create the synthetic symbols
> > at exactly those same addresses.
>
> No, if I understand correctly, Paul wants to use a stub symbol as a
> means of letting gdb know that it is in a plt call trampoline. Putting
> the symbol in .plt won't do that for you. Best just teach gdb what a
> plt call stub looks like.
There's two things necessary to make stepping and shared libraries play
nice.
1. Be able to unwind from the stub, so that we can see we've stepped
into something. We need symbols or some other similar code reading in
order to make this work.
2. Be able to identify this debug-info-less block of code as a stub,
so that we can skip it if we're going to step into a shared library
function that has debug info. I pointed Paul at the right function for
handling this earlier, but it's somewhat orthogonal.
--
Daniel Jacobowitz
CodeSourcery
next prev parent reply other threads:[~2006-05-13 14:58 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-05-12 22:50 PAUL GILLIAM
2006-05-12 23:12 ` Daniel Jacobowitz
2006-05-13 1:46 ` PAUL GILLIAM
2006-05-13 14:58 ` Alan Modra
2006-05-13 15:13 ` Daniel Jacobowitz [this message]
2006-05-15 3:34 ` Alan Modra
2006-05-15 15:10 ` Daniel Jacobowitz
2006-05-16 2:07 ` Alan Modra
2006-05-16 2:35 ` Daniel Jacobowitz
2006-05-16 7:18 ` Mark Kettenis
2006-05-16 17:53 ` Alan Modra
2006-05-19 17:38 ` PAUL GILLIAM
2006-05-20 1:32 ` Alan Modra
2006-06-23 21:06 ` PAUL GILLIAM
2006-06-23 21:22 ` Daniel Jacobowitz
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=20060513145829.GA3721@nevyn.them.org \
--to=drow@false.org \
--cc=amodra@bigpond.net.au \
--cc=gdb-patches@sources.redhat.com \
--cc=pgilliam@us.ibm.com \
/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