Proposal for STT_GNU_IFUNC and R_*_IRELATIVE

[H.J. Lu]

On Mon, Jun 1, 2009 at 1:12 PM, H.J. Lu <hjl.tools@gmail.com> wrote:
> On Mon, Jun 1, 2009 at 1:07 PM, Ian Lance Taylor
> <ianlancetaylor@gmail.com> wrote:
>>
>> "H.J. Lu" <hjl.tools@gmail.com> writes:
>>
>>> 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
>>>       the result of the corresponding R_*_RELATIVE relocation.
>>>
>>>       The purpose of this relocation to avoid name lookup for locally
>>>       defined STT_GNU_IFUNC symbols at load-time.
>>
>> How is the "corresponding R_*_RELATIVE relocation" determined?
>
> 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
>      the result of the corresponding R_*_RELATIVE relocation as
>      specified in the processor-specific ABI.
>
>

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,
the value of the STT_GNU_IFUNC symbol will be the address of the
real function.  We can't use the address of the PLT entry since
the PLT entry in a shared object may not be usable in non-shared object.

So the undefined STT_GNU_IFUNC symbol will have 2 different values.
Will it be a problem?


-- 
H.J.