From: Daniel Jacobowitz <drow@false.org>
To: PAUL GILLIAM <pgilliam@us.ibm.com>
Cc: gdb-patches@sources.redhat.com, Alan Modra <amodra@bigpond.net.au>
Subject: Re: [patch] Strange stepping behaviour with ppc32 with secure PLTs
Date: Fri, 12 May 2006 23:12:00 -0000 [thread overview]
Message-ID: <20060512225044.GA20706@nevyn.them.org> (raw)
In-Reply-To: <1147469935.3672.114.camel@dufur.beaverton.ibm.com>
On Fri, May 12, 2006 at 02:38:55PM -0700, PAUL GILLIAM wrote:
> >> I would rather have a GDB only solution.
> >
> > Why?
>
> I am not familiar enough with BFD to implement <foo@stub> symbols is a reasonable time.
I would like to introduce to you a magical technique for fixing PowerPC
bugs in BFD.
Hey, Alan, Paul's pointed out that there are no synthetic symbols for
the stubs in -msecure-plt mode. How hard would that be to fix?
> > What do you mean by "unknown section"?
>
> This is what I mean:
> (top-gdb) p *bfd_section
> $2 = {name = 0x1049c528 "*UND*", id = 1, index = 0, ...
That's not an "unknown" section. That's the undefined section! It
means that the symbol has a value, but is marked as undefined. This
is typical for PLT entry stubs, but it's an implementation choice;
I don't think the gABI has much to say about undefined symbols with
addresses.
The right thing to do then is probably to create the synthetic symbols
at exactly those same addresses.
> 2006-05-12 Paul Gilliam <pgilliam@us.ibm.com>
>
> * minsyms.c (lookup_minimal_symbol_by_pc_section): Don't ignore
> minimal symbols for solib trampolines just because they're in a
> different section than the PC.
This one I'd have to think about, but if synthetic symbols were not an
option, it might be reasonable. The second patch is definitely
incorrect. Generally any use of SECT_OFF_TEXT for something whose
section you don't know is incorrect.
--
Daniel Jacobowitz
CodeSourcery
next prev parent reply other threads:[~2006-05-12 22:50 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 [this message]
2006-05-13 1:46 ` PAUL GILLIAM
2006-05-13 14:58 ` Alan Modra
2006-05-13 15:13 ` Daniel Jacobowitz
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=20060512225044.GA20706@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