From: Daniel Jacobowitz <drow@false.org>
To: Ulrich Weigand <uweigand@de.ibm.com>
Cc: gdb-patches@sourceware.org
Subject: Re: [rfc] Fix mst_solib_trampoline symbol sections for PLT stubs
Date: Wed, 31 Oct 2007 18:06:00 -0000 [thread overview]
Message-ID: <20071031153420.GA7724@caradoc.them.org> (raw)
In-Reply-To: <200710311429.l9VETrn1025150@d12av02.megacenter.de.ibm.com>
On Wed, Oct 31, 2007 at 03:29:53PM +0100, Ulrich Weigand wrote:
> Daniel Jacobowitz:
>
> > Yes. But if the address of the function is not taken somewhere in the
> > executable, then the address of the undefined symbol will generally be
> > left at zero. That should be true most of the time. So while I don't
> > see anything wrong with your approach here, I'm surprised it fixed the
> > testsuite failures; why do they have non-zero addresses? If we're
> > taking their addresses in all cases, we need some new tests.
>
> I think this is because there are function calls from the main
> executable to those functions, and the main executable is not
> compiled with -fPIC. I understand those references will also
> cause the undefined symbol to carry the address of the main
> PLT call stub ...
Interesting. On most platforms, that's not necessary: LD only needs
to set a canonical address in the executable's symtab if the
executable takes the function's address, so this should only happen if
those non-PIC calls were indistinguishable from taking the address.
That's not implemented for PowerPC. I don't know if it's an ABI
requirement or just a missing optimization. Search for "st_value = 0"
in elf32-ppc.c versus elf32-i386.c.
So, this won't help everywhere or fix the root cause, but it does seem
like it would work for PowerPC.
--
Daniel Jacobowitz
CodeSourcery
next prev parent reply other threads:[~2007-10-31 15:34 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-10-31 2:09 Ulrich Weigand
2007-10-31 3:17 ` Daniel Jacobowitz
2007-10-31 17:56 ` Ulrich Weigand
2007-10-31 18:06 ` Daniel Jacobowitz [this message]
2007-10-31 20:41 ` Ulrich Weigand
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=20071031153420.GA7724@caradoc.them.org \
--to=drow@false.org \
--cc=gdb-patches@sourceware.org \
--cc=uweigand@de.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