Re: Cannot execute this command without a live selected thread.

[Doug Evans <dje@google.com>]

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 <palves@redhat.com>
 > Date: Fri, 24 Oct 2014 18:27:14 +0100
 > Subject: [PATCH] gdb/ 2014-10-24  Pedro Alves  <palves@redhat.com>
 > 
 > 	* 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)
 >  }
 >  
 >  \f
 > -/*  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?