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] |
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] |