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 12:19:14 -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>
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)
> }
>
>
> -/* 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?