This is the mail archive of the libc-alpha@sourceware.org mailing list for the glibc 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 Sat, Jun 6, 2009 at 5:55 AM, Roland McGrath <roland@redhat.com> wrote: > >> 1. A STT_GNU_IFUNC function should never access any data which need >> relocation. > > This does not seem like too much of a constraint, given that it also > unavoidably has to work before the DSO's initializers have run. > i.e., it is always special-purpose code that has to be written very > carefully. ?Being PIC code it should not be relying on much to have been > done before. ?It just has to avoid any PLT calls or other GOT use itself. > >> 2. Dynamic relocations against STT_GNU_INFUNC symbols should be >> placed after all other relocations. > > This is not possible, is it? ?Some DSO has a reference to "&strlen". > It has no idea that libc's definition will be STT_GNU_IFUNC. > The DSO might even have been linked against a libc.so that did > not use STT_GNU_IFUNC to define "strlen". > > The only other alternative to #1 that I see is some scheme whereby "&func" > will in all cases resolve to a PLT entry rather than the actual > STT_GNU_IFUNC symbol's st_value. ?i.e., the ifunc resolver is only called > for PLT resolution (and you can do all those last for BIND_NOW). > > e.g. in the defining DSO make ld generate a PLT entry with second symbol a > la executables' PLT entries, and then have rtld ignore the STT_GNU_IFUNC > symbol when resolving non-PLT relocs. ?(Seems highly dubious.) > > But in fact any scheme with that result might be undesireable in practice. > If the executable does not refer to "&func", then we don't have the pointer > equality issue and so DSOs with function pointer tables pointing to other > DSOs' entry points would do the extra indirection of a PLT jump when it > could be avoided except for this initialization order question. > > This patch implements #2. It may not solve all the problems. But it works for my simple testcase. -- H.J. ---- bfd/ 2009-06-06 H.J. Lu <hongjiu.lu@intel.com> * elf32-i386.c (elf_i386_link_hash_table): Add irelifunc. (elf_i386_link_hash_table_create): Initialize irelifunc. (elf_i386_check_relocs): Updated. Set up irelifunc for shared objects. (elf_i386_allocate_dynrelocs): Use irelifunc for dynamic relocation for non-GOT reference of STT_GNU_IFUNC symbol in shared objects. (elf_i386_relocate_section): Likewise. * elf64-x86-64.c (elf64_x86_64_link_hash_table): Add irelifunc. (elf64_x86_64_link_hash_table_create): Initialize irelifunc. (elf64_x86_64_check_relocs): Updated. Set up irelifunc for shared objects. (elf64_x86_64_allocate_dynrelocs): Use irelifunc for dynamic relocation for non-GOT reference of STT_GNU_IFUNC symbol in shared objects. (elf64_x86_64_relocate_section): Likewise. * elf-bfd.h (_bfd_elf_create_static_ifunc_sections): Renamed to ... (_bfd_elf_create_ifunc_sections): This. * elflink.c (_bfd_elf_create_static_ifunc_sections): Renamd to ... (_bfd_elf_create_ifunc_sections): This. Create .rel[a].ifunc for shared objects. ld/ 2009-06-06 H.J. Lu <hongjiu.lu@intel.com> * scripttempl/elf.sc: Add .rel.ifunc and .rela.ifunc.
Attachment:
binutils-ifunc-reloc-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] |