Generic System V Application Binary Interface Google Group

Re: Proposal for STT_GNU_IFUNC and R_*_IRELATIVE

rol...@redhat.com (Roland McGrath) — Mon, 08 Jun 2009 18:16:15 UT

You seem to have misunderstood the idea.

Re: Proposal for STT_GNU_IFUNC and R_*_IRELATIVE

rol...@redhat.com (Roland McGrath) — Mon, 08 Jun 2009 16:59:00 UT

You seem to have misunderstood the idea.

Re: [discuss] Proposal for STT_GNU_IFUNC and R_*_IRELATIVE

hjl.to...@gmail.com (H.J. Lu) — Mon, 08 Jun 2009 13:57:25 UT

Please try the current binutils in CVS. I think I have fixed all
problems. If not,
please open a bug report with a testcase.
Thanks.

Re: Proposal for STT_GNU_IFUNC and R_*_IRELATIVE

hjl.to...@gmail.com (H.J. Lu) — Sat, 06 Jun 2009 15:21:44 UT

This patch implements #2. It may not solve all the problems. But it
works for my simple testcase.

Re: Proposal for STT_GNU_IFUNC and R_*_IRELATIVE

rol...@redhat.com (Roland McGrath) — Sat, 06 Jun 2009 12:55:21 UT

This does not seem like too much of a constraint, given that it also
unavoidably has to work before the DSO's initializers have run.
i.e., it is always special-purpose code that has to be written very
carefully. Being PIC code it should not be relying on much to have been
done before. It just has to avoid any PLT calls or other GOT use itself.

Re: Proposal for STT_GNU_IFUNC and R_*_IRELATIVE

hjl.to...@gmail.com (H.J. Lu) — Sat, 06 Jun 2009 12:15:57 UT

Hi,
There is an ordering issue on STT_GNU_IFUNC functions. In shared object,
we need dynamic relocation to get the real function address when there is a
non-GOT reference against a STT_GNU_IFUNC symbols. A STT_GNU_IFUNC
function may use some data which need to be relocated first. Possible solutions:

Re: Proposal for STT_GNU_IFUNC and R_*_IRELATIVE

hjl.to...@gmail.com (H.J. Lu) — Sat, 06 Jun 2009 12:11:09 UT

Re: Proposal for STT_GNU_IFUNC and R_*_IRELATIVE

drep...@redhat.com (Ulrich Drepper) — Fri, 05 Jun 2009 05:30:48 UT

Re: Proposal for STT_GNU_IFUNC and R_*_IRELATIVE

drep...@redhat.com (Ulrich Drepper) — Fri, 05 Jun 2009 05:26:17 UT

Re: Proposal for STT_GNU_IFUNC and R_*_IRELATIVE

hjl.to...@gmail.com (H.J. Lu) — Thu, 04 Jun 2009 20:46:43 UT

There is an issue with STT_GNU_IFUNC symbols.
For branch, it is easy to understand. But it is unclear what the value
of STT_GNU_IFUNC symbol should be. In a non-shared object, the value
of the undefined STT_GNU_IFUNC symbol is the address of the PLT entry
since it will only be resolved at run-time. In a shared object,

Re: Proposal for STT_GNU_IFUNC and R_*_IRELATIVE

hjl.to...@gmail.com (H.J. Lu) — Thu, 04 Jun 2009 20:34:04 UT

Re: Proposal for STT_GNU_IFUNC and R_*_IRELATIVE

ianlancetay...@gmail.com (Ian Lance Taylor) — Wed, 03 Jun 2009 22:02:42 UT

How is the "corresponding R_*_RELATIVE relocation" determined?
Ian

Re: Proposal for STT_GNU_IFUNC and R_*_IRELATIVE

hjl.to...@gmail.com (H.J. Lu) — Wed, 03 Jun 2009 22:02:44 UT

On Mon, Jun 1, 2009 at 1:07 PM, Ian Lance Taylor
I added "as specified in the processor-specific ABI":
R_*_IRELATIVE
This relocation is similar to R_*_RELATIVE except that the
value used in this relocation is the program address returned
by the function, which takes no arguments, at the address of

Re: Proposal for STT_GNU_IFUNC and R_*_IRELATIVE

hjl.to...@gmail.com (H.J. Lu) — Mon, 01 Jun 2009 20:14:43 UT

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.

Re: Proposal for STT_GNU_IFUNC and R_*_IRELATIVE

hjl.to...@gmail.com (H.J. Lu) — Mon, 01 Jun 2009 20:12:44 UT