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]

Re: Proposal for STT_GNU_IFUNC and R_*_IRELATIVE


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]