Mirror of the gdb-patches mailing list
 help / color / mirror / Atom feed
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


  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