This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
Re: Cannot execute this command without a live selected thread.
- From: Doug Evans <dje at google dot com>
- To: Pedro Alves <palves at redhat dot com>
- Cc: Sandra Loosemore <sandra at codesourcery dot com>, gdb-patches at sourceware dot org
- Date: Fri, 24 Oct 2014 13:02:10 -0700
- Subject: Re: Cannot execute this command without a live selected thread.
- Authentication-results: sourceware.org; auth=none
- References: <544A7648 dot 6060102 at codesourcery dot com> <544A7930 dot 4040909 at redhat dot com> <544A8741 dot 9090705 at codesourcery dot com> <544A8B0C dot 5000509 at redhat dot com> <544A8F15 dot 9000906 at redhat dot com> <21578 dot 42546 dot 658345 dot 633154 at ruffy dot mtv dot corp dot google dot com> <544AAB39 dot 4030503 at redhat 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.