This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [PATCH] libffi powerpc64-*-linux* support
- From: Alan Modra <amodra at bigpond dot net dot au>
- To: Jakub Jelinek <jakub at redhat dot com>
- Cc: Tom Tromey <tromey at redhat dot com>, Janis Johnson <janis187 at us dot ibm dot com>, David Edelsohn <dje at watson dot ibm dot com>, gcc-patches at gcc dot gnu dot org, java-patches at gcc dot gnu dot org
- Date: Sun, 13 Apr 2003 16:19:15 +0930
- Subject: Re: [PATCH] libffi powerpc64-*-linux* support
- References: <20030410150010.GB16629@sunsite.ms.mff.cuni.cz>
On Thu, Apr 10, 2003 at 05:00:10PM +0200, Jakub Jelinek wrote:
> int main (void)
> {
> static char cl[32];
> ((void (*)(void))cl) ();
> }
> doesn't link on ppc64 because of undefined symbol .cl.0.
I think you can put this one down to the quirky ppc64 ABI. We use
function descriptors, defining two symbols for function "foo": foo,
the descriptor, and .foo, the code entry point. "bl .foo" says
branch and link to .foo if we have a definition in regular objects
given to the linker, or go via a stub that loads the descriptor "foo"
if "foo" (and ".foo") is dynamic. IMNSHO, these semantics are a
mistake. It would be better to simply use "bl foo", with the
meaning "branch and link to the function defined by descriptor foo".
The linker would then look at the descriptor, and if it is in a
regular object, emit a branch and link to the address given in the
descriptor. If the descriptor is dynamic, then you'd get a stub.
In the above case, gcc would emit "bl cl.0", and the linker would
look at cl.0, interpreting it as descriptor.
--
Alan Modra
IBM OzLabs - Linux Technology Centre