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

[Ulrich Drepper <drepper@redhat.com>]

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



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

- --
➧ Ulrich Drepper ➧ Red Hat, Inc. ➧ 444 Castro St ➧ Mountain View, CA ❖
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)

iEYEARECAAYFAkozQKYACgkQ2ijCOnn/RHS7ggCeIAD4keHAfellDswGieDBNSAX
/AgAoJKzcpoIcLyY25cJAfJ3FirrDd9k
=77gy
-----END PGP SIGNATURE-----