This is the mail archive of the binutils@sourceware.org mailing list for the binutils project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Preliminary prelink IFUNC support (x86-64 only so far), some binutils IFUNC issues


On Fri, Jun 12, 2009 at 11:01 PM, Ulrich Drepper <drepper@redhat.com> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Jakub Jelinek wrote:
>> On the attached ifunctest.c gcc -O2 -o ifunctest{,.c} compiles/links, but
>> no R_*_IRELATIVE relocation is emitted and not surprisingly it crashes
>> at runtime. ?Prelink testsuite contains similar testcase, just using
>> .globl or .globl/.hidden, instead of .local. ?I'd say .local @gnu_indirect_function
>> symbols should be supported as well.
>
> Indeed, there is no reason why .local symbols shouldn't be supported.

Please try the enclosed patch and let me know if it works.  Thanks.

>
>
>> The other issue can be seen with:
>> gcc -O2 -fpic -shared -o ifunc3lib1.{so,c}
>> gcc -O2 -o ifunc3 ./ifunc3lib1.so
>> ./ifunc3lib1
>> Here, &lib1t3 in the binary resolves to a .plt slot in the binary, while
>> &lib1t3 in the shared library resolves to the actual address the ifunc
>> returned.
>> Not sure what exactly we want to do here, but the function pointers should
>> be the same.
>
> It's tricky alright. ?There really isn't a good answer for this. ?The
> existing behavior is the only sensible solution. ?One could try to make
> things more complicated by changing the linker to associate the symbol
> with the PLT slot and somehow allow ld.so to recognize such symbols, but
> I think it's not worth it.
>
> This all comes about only because IFUNCs are used in situations where
> they really were not meant to be used. ?IFUNC are supposed to be
> definitions in DSOs which can be used in place of FUNC symbols. ?This
> will work without changes to any semantics.
>
> In your test case you're creating and IFUNC symbol in the executable.
> While I have no problem with supporting it this does mean the program
> author take responsibility for doing this. ?I think we can in this case
> very well live with the difference in function addresses.
>
> Therefore I suggest to leave this case and just document it.
>
> - --

That sounds reasonable.


-- 
H.J.

Attachment: binutils-local-ifunc-1.patch
Description: Text document


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]