Provide feature to build STT_IFUNC symbol type. It contains an address of a function to be called returning address which should be used by the symbol references later. There is now new gELF number: #define STT_IFUNC 7 Provided patch from Ulrich Drepper for glibc and mine for binutils. TODO: binutils - sort the relocations so that STT_IFUNC ones are the last ones. binutils - make the relocations working also for executables (not just shared libraries) prelink - (not a part of this Bug)
Created attachment 319264 [details] glibc patch.
Created attachment 319265 [details] binutils patch.
Created attachment 321935 [details] Second version of binutils patch with code to emit the relocs into the executable
Hi Guys, I have uploaded a revised version of the binutils patch which emits relocs against IFUNC symbols into the executables. I have not been able to arrange for the relocs to be sorted so that the IFUNC using ones are last, and I do not think that it is going to be possible to do this. This is because the relocs are created and stored on a per section basis (eg .rel[a].text for relocs against the .text section) but then the x86 linker script merges all of these reloc sections into one large .rel[a].plt section in the final executable. The only way to achieve the desired sorting would be to have a post-processing tool which reads in the .rel[a].plt section and then sorts it before re-emitting it. I think that the need for a sorted .rel[a].plt section can be avoided however - all that is needed is for the loader to perform two passes over the section, the first time ignoring relocas against IFUNC symbols and the second time ignoring relocs against non-IFUNC symbols. Cheers Nick
(In reply to comment #4) > I think that the need for a sorted .rel[a].plt section can be avoided however - > all that is needed is for the loader to perform two passes over the section, This means performing work at runtime thousands and millions of times instead of once at link-time. That's not a long-term solution. We can play around with the code as you have it now. So far, there is no need for the sorting anyway. The code used so far (and for x86/x86-64 in future) doesn't have dependencies. When we come across a situation where the sorting is really needed we can look at the problem again. Thanks for the patch.
Thanks, Nick, at least the elf32-i386.c/elf64-x86-64.c looks really tricky to me. [ The patch has some unrelated changes leftover(s) - like `.gnu.linkonce.r'. ]
Created attachment 322112 [details] Third version of patch - now with ifunc relocs placed in their own section
Hi Guys, I have uploaded a third version of the binutils patch. This version implements a possible solution to the reloc ordering problem by placing all of the STT_GNU_IFUNC referring relocs into their own section in the executable. Called .rel[a].ifunc.plt this section will be placed immediately after the .rel[a].plt section and is basically the same, except that it contains all of the relocs that refer to ifunc symbols. Cheers Nick PS. Jan - thanks for catching that .gnu.linkonce.r leakage - I have fixed it in this version of the patch.
A typo? It is called .rel[a].ifunc.dyn (not .rel[a].ifunc.plt). I would guess it should be after .rel[a].plt to have better functions availability in the ifunc resolving functions. Sure a nice functionality so quickly done. Relocation section '.rela.dyn' at offset 0x390 contains 1 entries: Offset Info Type Sym. Value Sym. Name + Addend 0000006009b0 000100000006 R_X86_64_GLOB_DAT 0000000000000000 __gmon_start__ + 0 Relocation section '.rela.ifunc.dyn' at offset 0x3a8 contains 1 entries: Offset Info Type Sym. Value Sym. Name + Addend 00000040059a 000500000002 R_X86_64_PC32 func() func - 4 Relocation section '.rela.plt' at offset 0x3c0 contains 3 entries: Offset Info Type Sym. Value Sym. Name + Addend 0000006009d0 000200000007 R_X86_64_JUMP_SLO 0000000000000000 puts + 0 0000006009d8 000300000007 R_X86_64_JUMP_SLO 0000000000000000 __libc_start_main + 0 0000006009e0 000400000007 R_X86_64_JUMP_SLO 0000000000000000 rand + 0
Hi Jan, > A typo? It is called .rel[a].ifunc.dyn (not .rel[a].ifunc.plt). Nope - it is deliberate. The normal relocations against code sections go into the .rel[a].dyn section so I chose to put the ifunc using versions into .rel[a].ifunc.dyn. That said if you want to change the name or placement of the section it is trivial to do - just edit the ld/scripttempl/elf.sc file. Cheers Nick
Created attachment 331348 [details] Revision of the v3 patch suitable for application to the current rawhide sources
Created attachment 331420 [details] Fix problem when the ifunc symbols are in a library, not an object file. Plus switch back to STT_GNU_IFUNC.
Hi Jan, I am closing this bug report for now. The latest rawhide binutils now has IFUNC support in it. Cheers Nick