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: Pedro Alves <palves at redhat dot com>
- To: Doug Evans <dje at google dot com>
- Cc: Sandra Loosemore <sandra at codesourcery dot com>, gdb-patches at sourceware dot org
- Date: Fri, 24 Oct 2014 20:40:41 +0100
- 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>
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,
Pedro Alves