From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 3356 invoked by alias); 24 Oct 2014 19:19:25 -0000 Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org Received: (qmail 3332 invoked by uid 89); 24 Oct 2014 19:19:20 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-3.5 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_LOW,RP_MATCHES_RCVD,SPF_PASS autolearn=ham version=3.3.2 X-HELO: mail-qa0-f73.google.com Received: from mail-qa0-f73.google.com (HELO mail-qa0-f73.google.com) (209.85.216.73) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES128-SHA encrypted) ESMTPS; Fri, 24 Oct 2014 19:19:18 +0000 Received: by mail-qa0-f73.google.com with SMTP id v10so194049qac.0 for ; Fri, 24 Oct 2014 12:19:16 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:mime-version:content-type :content-transfer-encoding:message-id:date:to:cc:subject:in-reply-to :references; bh=6CFV7I9mGdJZEhzlDMogBo4g//5ID0K5fuFSflYmF3Q=; b=jB+YPD549a+MUom1bmjwn6mw55tC7dlJ4t/GuPi72eb1pulQRF4ugfHVl7c1Pkpieh HDzxpa9eNOKUDcLNx1RQFla+d6b7Mz/NkmqP7qGGjD9IKDAZRmiii85lDmm1CcC0kZZq Y3vGOJgbg7qVmB80zs/sNCgwT4INw3RBokC+nHqrKdGgnwF6xFdHNg4dA9ZdjX3TB520 jvjzBP436MVmGebPzrWpskdEMcNm2/TgqvTd7v7ASypQXf38BEW6AXIGED2ADwQnJCMu /zAi6caG5xHPvpAcBLXhhNUWUm+9Sh69gklzk9MAAYtpjAbQ6Fhouk585QD70m2KMZBr 2mKQ== X-Gm-Message-State: ALoCoQm0o4LdtQQcuWR/JGvbQpZDkw8CurGcDlkHABuXF7Jncyrd0iZoCMNVot98x+NaVMyzKAuCq/IYQBjCnNIbfHoEW3tYnxRMKpnddbMiOOGQoCjwSu1bkEmAIH/GKbpvn7W6qwph4SMLLCiCA40toFdvCy+cU9Lj88sDBRlnnxWzKlPhBug= X-Received: by 10.224.128.7 with SMTP id i7mr8819546qas.9.1414178355830; Fri, 24 Oct 2014 12:19:15 -0700 (PDT) Received: from corpmail-nozzle1-1.hot.corp.google.com ([100.108.1.104]) by gmr-mx.google.com with ESMTPS id k66si297684yho.7.2014.10.24.12.19.15 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 24 Oct 2014 12:19:15 -0700 (PDT) Received: from ruffy.mtv.corp.google.com ([172.17.128.44]) by corpmail-nozzle1-1.hot.corp.google.com with ESMTP id QPTTl3hl.1; Fri, 24 Oct 2014 12:19:15 -0700 From: Doug Evans MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <21578.42546.658345.633154@ruffy.mtv.corp.google.com> Date: Fri, 24 Oct 2014 19:19:00 -0000 To: Pedro Alves Cc: Sandra Loosemore , gdb-patches@sourceware.org Subject: Re: Cannot execute this command without a live selected thread. In-Reply-To: <544A8F15.9000906@redhat.com> References: <544A7648.6060102@codesourcery.com> <544A7930.4040909@redhat.com> <544A8741.9090705@codesourcery.com> <544A8B0C.5000509@redhat.com> <544A8F15.9000906@redhat.com> X-IsSubscribed: yes X-SW-Source: 2014-10/txt/msg00670.txt.bz2 Pedro Alves writes: > On 10/24/2014 06:23 PM, Pedro Alves wrote: > > On 10/24/2014 06:07 PM, Sandra Loosemore wrote: > >> Sending packet: $?#3f...Packet received: S00 > >> Sending packet: $qfThreadInfo#bb...Packet received: l > > > > Huh, I think this is the problem. > > > > So this target supports qfThreadInfo, but then it's returning > > an empty thread list... remote_update_thread_list will delete > > threads from GDB's list that are not found in the thread list that > > the target reported. Why is the target reporting that empty list? > > > > See ab970af19746364a4f236bebc238ebb036adc898. > > > > We may be able add a workaround for this. :-/ Just in case, > > can you confirm that the current thread's ptid (inferior_ptid) > > is magic_null_ptid? > > Please give this a try. > > >From 2062235a91a3c69e73c39b0f8a4f78f4ec396931 Mon Sep 17 00:00:00 2001 > From: Pedro Alves > Date: Fri, 24 Oct 2014 18:27:14 +0100 > Subject: [PATCH] gdb/ 2014-10-24 Pedro Alves > > * remote.c (remote_thread_alive): New, factored out from ... > (remote_thread_alive): ... this. > (remote_update_thread_list): Bail out before deleting threads if > the target returned an empty list, and, the current thread has a > magic/fake ptid. > --- > gdb/remote.c | 35 ++++++++++++++++++++++++++++++++--- > 1 file changed, 32 insertions(+), 3 deletions(-) > > diff --git a/gdb/remote.c b/gdb/remote.c > index 20f2988..affc7c2 100644 > --- a/gdb/remote.c > +++ b/gdb/remote.c > @@ -1842,11 +1842,11 @@ set_general_process (void) > } > > > -/* Return nonzero if the thread PTID is still alive on the remote > - system. */ > +/* Return nonzero if this is the main thread that we made up ourselves > + to model non-threaded targets as single-threaded. */ > > static int > -remote_thread_alive (struct target_ops *ops, ptid_t ptid) > +remote_thread_always_alive (struct target_ops *ops, ptid_t ptid) > { > struct remote_state *rs = get_remote_state (); > char *p, *endp; > @@ -1861,6 +1861,23 @@ remote_thread_alive (struct target_ops *ops, ptid_t ptid) > multi-threading. */ > return 1; > > + return 0; > +} > + > +/* Return nonzero if the thread PTID is still alive on the remote > + system. */ > + > +static int > +remote_thread_alive (struct target_ops *ops, ptid_t ptid) > +{ > + struct remote_state *rs = get_remote_state (); > + char *p, *endp; > + > + /* Check if this is a thread that we made up ourselves to model > + non-threaded targets as single-threaded. */ > + if (remote_thread_always_alive (ops, ptid)) > + return 1; > + > p = rs->buf; > endp = rs->buf + get_remote_packet_size (); > > @@ -2780,6 +2797,18 @@ remote_update_thread_list (struct target_ops *ops) > > got_list = 1; > > + if (VEC_empty (thread_item_t, context.items) > + && remote_thread_always_alive (ops, inferior_ptid)) > + { > + /* Some targets don't really support threads, but still > + reply an (empty) thread list in response to the thread > + listing packets, instead of replying "packet not > + supported". Exit early so we don't delete the main > + thread. */ > + do_cleanups (old_chain); > + return; > + } > + > /* CONTEXT now holds the current thread list on the remote > target end. Delete GDB-side threads no longer found on the > target. */ I looked at the current remote_thread_alive. It has this: if (ptid_get_pid (ptid) != 0 && ptid_get_lwp (ptid) == 0) /* The main thread is always alive. This can happen after a vAttach, if the remote side doesn't support multi-threading. */ return 1; pid != 0 && lwp == 0 -> main thread? That sounds odd. Do you know why the test is the way it is?