Symbol refcounting for STT_GNU_IFUNC symbols

[H.J. Lu]

On Mon, Jul 5, 2010 at 9:05 AM, Stephen Clarke <stephen.clarke@st.com> wrote:
> H.J. Lu wrote:
>>
>> On Fri, Jul 2, 2010 at 7:47 AM, Stephen Clarke <stephen.clarke@st.com>
>> wrote:
>>>
>>> In bfd/elf32-386.c, elf_i386_check_relocs(), for R_386_GOT32 and
>>> R_386_GOTOFF relocations with a symbol with STT_GNU_IFUNC type, the
>>> h->got.refcount is incremented:
>>>
>>>               case R_386_GOT32:
>>>               case R_386_GOTOFF:
>>>                 h->got.refcount += 1;
>>>
>>> I guess this is because the mechanism for IFUNC symbols requires a GOT
>>> entry (even for a GOTOFF relocation which does not normally require a
>>> GOT entry).
>>>
>>> However, there is no corresponding decrement in the
>>> elf_i386_gc_sweep_hook() if the relocation is removed.
>>> Is this just a minor (safe) inaccuracy, or is there some reason why the
>>> refcount cannot be decremented in elf_i386_gc_sweep_hook()?
>>>
>>
>> It could be an oversight.  Do you have an testcase?
>
> I don't have a real testcase ... the question arose from a discussion
> with colleagues about the refcounting in elf32-sh.c ... and since that is
> based on the refcounting in elf32-i386.c, we reviewed that.
> (I know ifunc is not supported yet in elf32-sh.c: our original
> discussion was unrelated to ifunc symbols.)
>
> However, here's a synthetic testcase:
> $ cat test.s
>        .section .text.foo,"ax",@progbits
>        .type foo, @function
> foo:
>        .global foo
>        movl ifunc@GOT(%ecx), %eax
>        ret
>
>        .section .text.bar,"ax",@progbits
>        .type bar, @function
> bar:
>        .global bar
>        ret
>
>        .section .text.ifunc,"ax",@progbits
>        .type ifunc, @gnu_indirect_function
> ifunc:
>        ret
>
> $ as -o test.o test.s
> $ ld -e bar --gc-sections test.o
>
> If I use a recent version of binutils:
> $ ld -v
> GNU ld (GNU Binutils) 2.20.51.20100702
>
> then for the ld command I get segv, i.e.
> $ ld -e bar --gc-sections test.o
> Segmentation fault
>
> but if I hack out the cause of that, then I get an executable in
> which garbage collection has removed all the original sections that
> refer to the ifunc symbol, but there is still a plt entry, got entry
> and  dynamic relocation for the ifunc symbol.
>
> $ objdump -h -d a.out
>
> a.out:     file format elf32-i386
>
> Sections:
> Idx Name          Size      VMA       LMA       File off  Algn
>  0 .rel.plt      00000008  08048074  08048074  00000074  2**2
>                  CONTENTS, ALLOC, LOAD, READONLY, DATA
>  1 .plt          00000010  0804807c  0804807c  0000007c  2**2
>                  CONTENTS, ALLOC, LOAD, READONLY, CODE
>  2 .text         00000001  0804808c  0804808c  0000008c  2**0
>                  CONTENTS, ALLOC, LOAD, READONLY, CODE
>  3 .got.plt      00000010  08049090  08049090  00000090  2**2
>                  CONTENTS, ALLOC, LOAD, DATA
>
> Disassembly of section .plt:
>
> 0804807c <.plt>:
>  804807c:       ff 25 9c 90 04 08       jmp    *0x804909c
>  8048082:       68 00 00 00 00          push   $0x0
>  8048087:       e9 00 00 00 00          jmp    804808c <bar>
>
> Disassembly of section .text:
>
> 0804808c <bar>:
>  804808c:       c3                      ret
>

Please open a bug report with this testcase. I will investigate it.

Thanks.


-- 
H.J.