From patchwork Fri Dec 26 20:31:08 2014 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Pedro Alves X-Patchwork-Id: 4430 Received: (qmail 32660 invoked by alias); 26 Dec 2014 20:32:02 -0000 Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Unsubscribe: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org Delivered-To: mailing list gdb-patches@sourceware.org Received: (qmail 32626 invoked by uid 89); 26 Dec 2014 20:32:00 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.0 required=5.0 tests=AWL, BAYES_00, SPF_HELO_PASS, SPF_PASS, T_RP_MATCHES_RCVD autolearn=ham version=3.3.2 X-HELO: mx1.redhat.com Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES256-GCM-SHA384 encrypted) ESMTPS; Fri, 26 Dec 2014 20:31:58 +0000 Received: from int-mx13.intmail.prod.int.phx2.redhat.com (int-mx13.intmail.prod.int.phx2.redhat.com [10.5.11.26]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id sBQKVvEh015544 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL) for ; Fri, 26 Dec 2014 15:31:57 -0500 Received: from brno.lan (ovpn01.gateway.prod.ext.ams2.redhat.com [10.39.146.11]) by int-mx13.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id sBQKVG2s011395 for ; Fri, 26 Dec 2014 15:31:56 -0500 From: Pedro Alves To: gdb-patches@sourceware.org Subject: [PATCH 5/8] linux-nat.c: always mark execing LWP as resumed Date: Fri, 26 Dec 2014 20:31:08 +0000 Message-Id: <1419625871-28848-6-git-send-email-palves@redhat.com> In-Reply-To: <1419625871-28848-1-git-send-email-palves@redhat.com> References: <1419625871-28848-1-git-send-email-palves@redhat.com> A subsequent patch will make the Linux backend's target_wait method pull all events out of the kernel (with waitpid) and store them as pending status in the LWP structure if no pending status was already available. Then, the backend goes over the pending statuses and pick one to report to the core. With that, the existing thread-execl.exp test exposes a bug, like: (gdb) set scheduler-locking on (gdb) PASS: gdb.threads/thread-execl.exp: schedlock on: set scheduler-locking on next FAIL: gdb.threads/thread-execl.exp: schedlock on: get to main in new image (timeout) Recall that when the non-leader thread execs, all threads in the process die, the execing thread changes its pid to the tgid, and then waitpid returns an exec event to the tgid. If GDB didn't resume the leader LWP, then GDB sees an event for an LWP that was supposedly stopped, and thus not marked as resumed. Because the code that picks a pending event to report to the core ignores not-resumed LWPs: /* Return non-zero if LP has a wait status pending. */ static int status_callback (struct lwp_info *lp, void *data) { /* Only report a pending wait status if we pretend that this has indeed been resumed. */ if (!lp->resumed) return 0; the event ends up pending forever, thus the timeout. gdb/ 2014-12-26 Pedro Alves * linux-nat.c (linux_handle_extended_wait) : Set the LWP's 'resumed' flag. --- gdb/linux-nat.c | 4 ++++ 1 file changed, 4 insertions(+) diff --git a/gdb/linux-nat.c b/gdb/linux-nat.c index 8346c55..c50a59f 100644 --- a/gdb/linux-nat.c +++ b/gdb/linux-nat.c @@ -2007,6 +2007,10 @@ linux_handle_extended_wait (struct lwp_info *lp, int status, ourstatus->value.execd_pathname = xstrdup (linux_child_pid_to_exec_file (NULL, pid)); + /* The thread that execed must have been resumed, but, when a + thread execs, it changes its tid to the tgid, and the old + tgid thread might have not been resumed. */ + lp->resumed = 1; return 0; }