[Bug libc/21936] gcc build hangs with glibc 2.26 (conftest about static binaries dlopening themselves)

["fweimer at redhat dot com" <sourceware-bugzilla at sourceware dot org>]

https://sourceware.org/bugzilla/show_bug.cgi?id=21936

--- Comment #6 from Florian Weimer <fweimer at redhat dot com> ---
Thanks.  The binary is incorrectly linked.

_dl_dst_count calls strchr:

Dump of assembler code for function _dl_dst_count:
…
   0x080729bb <+123>:   call   0x805c6e0 <strchr>

But strchr is not an implementation of strchr, but the IFUNC resolver for
strchr:

Dump of assembler code for function strchr:
   0x0805c6e0 <+0>:     lea    0x805c710,%eax
   0x0805c6e6 <+6>:     testl  $0x4000000,0x80d7574
   0x0805c6f0 <+16>:    je     0x805c70a <strchr+42>
   0x0805c6f2 <+18>:    lea    0x8069750,%eax
   0x0805c6f8 <+24>:    testl  $0x4,0x80d75a0
   0x0805c702 <+34>:    je     0x805c70a <strchr+42>
   0x0805c704 <+36>:    lea    0x8069370,%eax
   0x0805c70a <+42>:    ret    

(gdb) info symb 0x805c710
__strchr_ia32 in section .text of t

This could be a binutils bug, or another toolchain issue.  We don't see it with
our binutils 2.29 builds, and we have IFUNCs enabled in GCC.

For strchr.o from Fedora 27's libc.a, I get this:

$ readelf -W -a strchr.o | grep IFUNC
     6: 00000000    43 IFUNC   GLOBAL DEFAULT    1 strchr

So the function is correctly marked as an IFUNC resolver.  dl-load.o contains a
direct call to strchr.  ld then generates a PLT stub for strchr which jumps to
the function pointer previously initialized with the result of the IFUNC
resolver.

In your binary, the PLT stub is missing, and there is a direct call to the
IFUNC resolver instead, which is obviously wrong.  This could be an issue
present in libc.a already, or it could be an ld bug which manifests only during
the final static link.

-- 
You are receiving this mail because:
You are on the CC list for the bug.