From patchwork Fri Jul 10 20:50:20 2015 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Kevin Buettner X-Patchwork-Id: 7637 Received: (qmail 77848 invoked by alias); 10 Jul 2015 20:50:27 -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 77837 invoked by uid 89); 10 Jul 2015 20:50:27 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-3.8 required=5.0 tests=AWL, BAYES_00, KAM_LAZY_DOMAIN_SECURITY, RP_MATCHES_RCVD, SPF_HELO_PASS autolearn=no 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, 10 Jul 2015 20:50:26 +0000 Received: from int-mx10.intmail.prod.int.phx2.redhat.com (int-mx10.intmail.prod.int.phx2.redhat.com [10.5.11.23]) by mx1.redhat.com (Postfix) with ESMTPS id 4F33D36363C for ; Fri, 10 Jul 2015 20:50:25 +0000 (UTC) Received: from pinnacle.lan (ovpn-113-81.phx2.redhat.com [10.3.113.81]) by int-mx10.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id t6AKoOV9018516 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA256 bits=256 verify=NO) for ; Fri, 10 Jul 2015 16:50:25 -0400 Date: Fri, 10 Jul 2015 13:50:20 -0700 From: Kevin Buettner To: gdb-patches@sourceware.org Subject: [PATCH] remote.c: Ensure that inferior_ptid is on the thread list Message-ID: <20150710135020.573a8f6c@pinnacle.lan> MIME-Version: 1.0 X-IsSubscribed: yes When using GDB to debug an RX target using the GDB remote protocol, using a Renesas supplied debug agent, I encountered the following assertion error: thread.c:85: internal-error: inferior_thread: Assertion `tp' failed. A problem internal to GDB has been detected, further debugging may prove unreliable. Create a core file of GDB? (y or n) n Command aborted. The errant line of code (after some analysis) seems to be this line in remote_start_remote. (I've provided the preceding comment as context.) /* We have thread information; select the thread the target says should be current. If we're reconnecting to a multi-threaded program, this will ideally be the thread that last reported an event before GDB disconnected. */ inferior_ptid = get_current_thread (wait_status); get_current_thread() calls stop_reply_extract_thread with the wait status. This returns null_ptid. get_current_thread() then calls remote_current_thread with (a null) inferior_ptid. After the calls to putpkt() and getpkt(), rs->buf[0] is 'Q', so read_ptid() is called and its result is returned. The buffer passed to read_ptid() is " not supported". read_ptid ultimately returns a ptid of {pid = 4200, lwp = 0, tid = 0}. However, this thread is not on the thread list. An earlier call to target_update_thread_list() had placed {pid = 42000, lwp = 1, tid = 0} on the list. This is the only thread in the list. When these calls ultimately return to remote_start_remote(), inferior_ptid gets set to {pid = 4200, lwp = 0, tid = 0}, which (again) is not on the thread list. I'm guessing that the string " not supported" is coming from the debug agent. If so, it should be fixed, but I don't see a reason to not consult the thread list in order to place a valid thread id in inferior_ptid. This (consultation of the thread list) is what is done when inferior_ptid is null_ptid: if (ptid_equal (inferior_ptid, null_ptid)) { /* Odd... The target was able to list threads, but not tell us which thread was current (no "thread" register in T stop reply?). Just pick the first thread in the thread list then. */ inferior_ptid = thread_list->ptid; } This change simply extends the test so that the "Odd..." case will be used when inferior_ptid is not in the current set of threads. gdb/ChangeLog: * remote.c (remote_start_remote): Ensure that inferior_ptid is set to a ptid from the thread list. --- gdb/remote.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/gdb/remote.c b/gdb/remote.c index 9d97f6b..2f2bb28 100644 --- a/gdb/remote.c +++ b/gdb/remote.c @@ -3695,7 +3695,8 @@ remote_start_remote (int from_tty, struct target_ops *target, int extended_p) multi-threaded program, this will ideally be the thread that last reported an event before GDB disconnected. */ inferior_ptid = get_current_thread (wait_status); - if (ptid_equal (inferior_ptid, null_ptid)) + if (ptid_equal (inferior_ptid, null_ptid) + || find_thread_ptid (inferior_ptid) == NULL) { /* Odd... The target was able to list threads, but not tell us which thread was current (no "thread"