This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: Unreviewed patch for PR 11297
- From: Jakub Jelinek <jakub at redhat dot com>
- To: David Edelsohn <dje at watson dot ibm dot com>
- Cc: gcc-patches at gcc dot gnu dot org
- Date: Mon, 7 Jul 2003 16:16:59 -0400
- Subject: Re: Unreviewed patch for PR 11297
- References: <jakub@redhat.com> <200307072010.QAA05908@makai.watson.ibm.com>
- Reply-to: Jakub Jelinek <jakub at redhat dot com>
On Mon, Jul 07, 2003 at 04:10:59PM -0400, David Edelsohn wrote:
> >> What is the benefit of the vthunk static alias anyway?
>
> Jakub> Avoiding call through .plt or .got access in most arches, often saving
> Jakub> a dynamic relocation.
>
> I think if I understand the purpose, then all ABI_AIX systems do
> that automatically in the linker: the caller always treats the call as
> local and the linker creates a stub if it is not.
At least for ELF, the linker cannot do that in a shared library if the
symbol is not local - it always has to create .plt stub.
This is because ELF spec allows overriding this symbol by an exported symbol
with the same name (and symbol version) defined in some shared library
earlier in symbol lookup scope or exported from the binary.
Linker doesn't know anything about C++ virtual thunks and so
cannot treat them specially, while the C++ frontend knows it is always
emitting virtual thunks together with the method they are calling, so if
the method symbol would be overridden by some other shared library
or the main binary, a virtual thunk in that other shared library or binary
would be called instead.
> Okay, go ahead and commit the patch. We'll see what breaks -- if
> we can tell amid the current mess.
Thanks.
Jakub