From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <gcc-bugs-return-455725-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Received: (qmail 26770 invoked by alias); 6 Jul 2014 20:29:58 -0000
Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm
Precedence: bulk
List-Id: <gcc-bugs.gcc.gnu.org>
List-Archive: <http://gcc.gnu.org/ml/gcc-bugs/>
List-Post: <mailto:gcc-bugs@gcc.gnu.org>
List-Help: <mailto:gcc-bugs-help@gcc.gnu.org>
Sender: gcc-bugs-owner@gcc.gnu.org
Received: (qmail 26613 invoked by uid 48); 6 Jul 2014 20:29:52 -0000
From: "kumba at gentoo dot org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug c++/61538] g++ compiled binary, linked to glibc libpthread, hangs on SGI MIPS R1x000 systems on Linux
Date: Sun, 06 Jul 2014 20:29:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: c++
X-Bugzilla-Version: 4.9.0
X-Bugzilla-Keywords:
X-Bugzilla-Severity: major
X-Bugzilla-Who: kumba at gentoo dot org
X-Bugzilla-Status: UNCONFIRMED
X-Bugzilla-Priority: P3
X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org
X-Bugzilla-Target-Milestone: ---
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields:
Message-ID: <bug-61538-4-GnbKBuDgyv@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-61538-4@http.gcc.gnu.org/bugzilla/>
References: <bug-61538-4@http.gcc.gnu.org/bugzilla/>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 7bit
X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/
Auto-Submitted: auto-generated
MIME-Version: 1.0
X-SW-Source: 2014-07/txt/msg00316.txt.bz2

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

--- Comment #12 from Joshua Kinard <kumba at gentoo dot org> ---
So I discovered the presence of the --disable-linux-futex configure flag,
rebuilt gcc-4.9.0 with it, and tested my conftest.c testcase, and can confirm
that the resulting binary no longer hangs on a futex syscall.  It still calls
futex twice somewhere in the call chain, but that's probably expected behavior
or a different library (pthreads?):

set_tid_address(0x77256068)             = 10805
set_robust_list(0x77256070, 12)         = 0
futex(0x7fcb46b8, FUTEX_WAKE_PRIVATE, 1) = 0
futex(0x7fcb46b8, FUTEX_WAIT_BITSET_PRIVATE|FUTEX_CLOCK_REALTIME, 1, NULL, 0) =
-1 EINVAL (Invalid argument)
rt_sigaction(SIGRT_0, {0x8, [],
SA_RESTART|SA_INTERRUPT|SA_NODEFER|SA_SIGINFO|0x7205b94}, NULL, 16) = 0
rt_sigaction(SIGRT_1, {0x10000008, [],
SA_RESTART|SA_INTERRUPT|SA_NODEFER|SA_SIGINFO|0x7205a34}, NULL, 16) = 0
rt_sigprocmask(SIG_UNBLOCK, [RT_0 RT_1], NULL, 16) = 0
getrlimit(RLIMIT_STACK, {rlim_cur=8192*1024, rlim_max=2147483647}) = 0
futex(0x771fb9a0, FUTEX_WAKE_PRIVATE, 2147483647) = 0
futex(0x771fb9a4, FUTEX_WAKE_PRIVATE, 2147483647) = 0
exit_group(0)                           = ?
+++ exited with 0 +++

So, not the ideal solution, as I assume under a Linux kernel, there is some
advantage to using the futex syscall within gcc, but I don't know how that will
affect things.  I'll try to compile glibc-2.19 with gcc-4.9.0 and see if the
'sln' static binary also hangs with this change.