This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: IFUNC resolvers for non-function symbols
- From: Szabolcs Nagy <szabolcs dot nagy at arm dot com>
- To: Florian Weimer <fweimer at redhat dot com>, GNU C Library <libc-alpha at sourceware dot org>
- Cc: <nd at arm dot com>
- Date: Tue, 24 Jan 2017 14:26:22 +0000
- Subject: Re: IFUNC resolvers for non-function symbols
- Authentication-results: sourceware.org; auth=none
- Authentication-results: spf=none (sender IP is ) smtp.mailfrom=Szabolcs dot Nagy at arm dot com;
- Nodisclaimer: True
- References: <3e0801af-194a-6890-df75-1708ed3298b2@redhat.com> <58875CCC.8090209@arm.com> <0f9ba169-1bfb-cc3b-50e6-0963e0ccfeaa@redhat.com>
- Spamdiagnosticmetadata: NSPM
- Spamdiagnosticoutput: 1:99
On 24/01/17 14:08, Florian Weimer wrote:
> On 01/24/2017 02:55 PM, Szabolcs Nagy wrote:
>> the ifunc spec i know about
>>
>> https://sites.google.com/site/x32abi/documents
>>
>> says
>>
>> STT_GNU_IFUNC
>>
>> This symbol type is the same as STT_FUNC except that it always
>> points to a function or piece of executable code which takes no
>> arguments and returns a function pointer. [..]
>>
>> this implies to me that ifunc resolver is not applicable to data.
>
> But this bit applies to the address of the resolver, not the address returned from it.
this bit applies to the ifunc resolved symbol, not to the
symbol of the resolver (which should not be in the dynamic
symbol table or at least should be bound locally if it is).
function and object symbols should be possible to distinguish
even if they are ifunc resolved so for ifunc resolved objects
you would need STT_GNU_IOBJECT or similar i think.
and the resolver is specified to return a function pointer
which is not suitable for objects.