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

[Doug Evans <dje at google dot com>]

Pedro Alves writes:
 > On 10/24/2014 08:19 PM, Doug Evans wrote:
 > 
 > > 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?
 > 
 > If it's the 0 part you're calling out as odd, it's that way
 > because we didn't have a thread id back when we created
 > the thread:
 > 
 > static void
 > extended_remote_attach_1 (struct target_ops *target, const char *args,
 > 			  int from_tty)
 > {
 >   struct remote_state *rs = get_remote_state ();
 >   int pid;
 >   char *wait_status = NULL;
 > 
 >   pid = parse_pid_to_attach (args);
 > 
 > ...
 >   set_current_inferior (remote_add_inferior (0, pid, 1));
 > 
 >   inferior_ptid = pid_to_ptid (pid);
 > 
 > ...
 >     {
 >       /* Now, if we have thread information, update inferior_ptid.  */
 >       inferior_ptid = remote_current_thread (inferior_ptid);
 > 
 >       /* Add the main thread to the thread list.  */
 >       add_thread_silent (inferior_ptid);
 >     }
 > ...
 > 
 > 
 > Later on, when we get the first stop event back, we may or may not
 > find a thread id to use:
 > 
 > static void
 > remote_notice_new_inferior (ptid_t currthread, int running)
 > {
 > ...
 >       if (ptid_is_pid (inferior_ptid)
 > 	  && pid == ptid_get_pid (inferior_ptid))
 > 	{
 > 	  /* inferior_ptid has no thread member yet.  This can happen
 > 	     with the vAttach -> remote_wait,"TAAthread:" path if the
 > 	     stub doesn't support qC.  This is the first stop reported
 > 	     after an attach, so this is the main thread.  Update the
 > 	     ptid in the thread list.  */
 > 	  if (in_thread_list (pid_to_ptid (pid)))
 > 	    thread_change_ptid (inferior_ptid, currthread);
 > 	  else
 > 	    {
 > 	      remote_add_thread (currthread, running);
 > 	      inferior_ptid = currthread;
 > 	    }
 > 	  return;
 > 	}
 > 
 > If we never see any stop reply with a thread id, or the target
 > doesn't support any thread listing packets, it must be that the
 > target doesn't really support threads, so we shouldn't ever delete
 > that thread, for we made it up.  We use "pid != 0 && lwp == 0"
 > rather than magic_null_ptid as the former carries more info, for
 > including the PID that the user specified on "attach PID" (and a stop
 > reply with a thread id may come along), so we can put that PID in
 > inferior->pid too and display it in "info inferiors", etc., and preserve
 > the invariant that starting from a ptid we can find the corresponding
 > inferior, matching by pid.  We shouldn't ask the target whether
 > that thread is alive, as it's a thread id we made up.
 > 
 > BTW, we do the same in native debugging.  E.g., see inf-ptrace.c:
 > 
 >   inferior_ptid = pid_to_ptid (pid);
 > 
 >   /* Always add a main thread.  If some target extends the ptrace
 >      target, it should decorate the ptid later with more info.  */
 >   add_thread_silent (inferior_ptid);
 > 
 > If the inferior is truly non-threaded, and doesn't have any other
 > threads, it's main/single thread can well end up with a ptid with only
 > the pid field set; there's no conflict with using (pid,0,0) to refer
 > to all threads of the process as there'll be only one in that
 > process anyway.

Thanks, that's helpful.

Not all targets use ptid.lwp.
Does remote.c not support targets that use tid instead of lwp?
I guess not.