[Bug c++/61538] g++ compiled binary, linked to glibc libpthread, hangs on SGI MIPS R1x000 systems on Linux

kumba at gentoo dot org gcc-bugzilla@gcc.gnu.org
Sat Jun 21 01:59:00 GMT 2014


https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61538

--- Comment #11 from Joshua Kinard <kumba at gentoo dot org> ---
I also have another test case from glibc itself, where when compiling
glibc-2.19 w/ gcc-4.8.x or greater, at the end, it creates a statically-linked
version of 'ln' as 'sln', and tries to run that.  That binary also hangs, but
it hangs in glibc-specific code:

nptl/sysdeps/unix/sysv/linux/lowlevellock.c:
  >¦32        while (atomic_exchange_acq (futex, 2) != 0)
   ¦33          lll_futex_wait (futex, 2, LLL_PRIVATE);
   ¦34      }

Which looks like it's hanging in lll_futex_wait().  If I set a breakpoint on
that address in the asm layout, I can see this:

Breakpoint 1, 0x00423bf4 in __lll_lock_wait_private (futex=0x4a215c
<_IO_stdfile_1_lock>) at ../nptl/sysdeps/unix/sysv/linux/lowlevellock.c:33
   ¦0x423be0 <__lll_lock_wait_private+32>   0x7c03e83b
   ¦0x423be4 <__lll_lock_wait_private+36>   li     a2,2
   ¦0x423be8 <__lll_lock_wait_private+40>   lw     a1,-29832(v1)
   ¦0x423bec <__lll_lock_wait_private+44>   move   a3,zero
   ¦0x423bf0 <__lll_lock_wait_private+48>   li     v0,4238
B+>¦0x423bf4 <__lll_lock_wait_private+52>   syscall

(gdb) x/6i 0x4a215c
   0x4a215c <_IO_stdfile_1_lock>:       srl     zero,zero,0x0
   0x4a2160 <_IO_stdfile_1_lock+4>:     nop
   0x4a2164 <_IO_stdfile_1_lock+8>:     nop
   0x4a2168 <_IO_stdfile_0_lock>:       nop
   0x4a216c <_IO_stdfile_0_lock+4>:     nop
   0x4a2170 <_IO_stdfile_0_lock+8>:     nop

I did find two very recent patches on libc-alpha that deal specifically with
lowlevellock.h, by replacing it (and all other arch-specific variants) with a
generic lowlevellock.h file:
https://sourceware.org/ml/libc-alpha/2014-06/msg00174.html
https://sourceware.org/ml/libc-alpha/2014-06/msg00419.html

And this interesting comment:
https://sourceware.org/ml/libc-alpha/2014-06/msg00184.html

I am going to try rebuilding glibc with those and see if I am still getting
hangs or not.


More information about the Gcc-bugs mailing list