This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: Proposal for STT_GNU_IFUNC and R_*_IRELATIVE
- From: "H.J. Lu" <hjl dot tools at gmail dot com>
- To: generic-abi at googlegroups dot com
- Cc: GNU C Library <libc-alpha at sourceware dot org>, discuss at x86-64 dot org, Binutils <binutils at sourceware dot org>, IA32 System V Application Binary Interface <ia32-abi at googlegroups dot com>, Nick Clifton <nickc at redhat dot com>, Ulrich Drepper <drepper at redhat dot com>
- Date: Mon, 1 Jun 2009 13:14:43 -0700
- Subject: Re: Proposal for STT_GNU_IFUNC and R_*_IRELATIVE
- References: <6dc9ffc80905251156p1ab274aey8e52be086fd88749@mail.gmail.com> <6dc9ffc80906011246v3681460are7c2a0de5209a1e4@mail.gmail.com> <20090601200035.B343BFC3C7@magilla.sf.frob.com>
On Mon, Jun 1, 2009 at 1:00 PM, Roland McGrath <roland@redhat.com> wrote:
>
> To be a full description, it should say something about the ABI of the
> entry-point that returns the function pointer. ?Is it "the prevailing
> normal ABI" for a function of no arguments returning a pointer to function?
> i.e., with whatever call-clobbered registers et al that generically entails.
> Or is it a special-case ABI to be defined precisely in the
> processor-specific spec? ?However much or little the specification of the
> ELF feature per se wants to say about this, it should be explicit about
> what it does or doesn't specify for it.
>
>
How about this:
The calling convention of the STT_GNU_IFUNC function, which takes no
arguments and returns a function pointer, should follow the
processor-specific ABI. All rules for caller-saved and callee-saved
registers apply.
--
H.J.