Cannot execute this command without a live selected thread.

Cannot execute this command without a live selected thread.

[Sandra Loosemore]

Yesterday I refreshed my build tree for testing some further nios2 
patches, and started seeing a whole lot of this in my test results:

(gdb) target remote qa8-centos32-cs:10514
Remote debugging using qa8-centos32-cs:10514
(gdb) set remote hardware-watchpoint-limit 1
(gdb) set mem inaccessible-by-default on
(gdb) load
Loading section .text, size 0x844 lma 0x10000000
Loading section .eh_frame, size 0x4 lma 0x10000844
Loading section .rodata, size 0x120 lma 0x10000848
Loading section .data, size 0x428 lma 0x10000968
Start address 0x10000040, load size 3472
Transfer rate: 41 KB/sec, 868 bytes/write.
(gdb) continue
Continuing.
Cannot execute this command without a live selected thread.
(gdb) ERROR: couldn't run to breakpoint

I think the checkout I used for testing the last nios2 patch I submitted 
was a couple weeks old.  Pedro, I see you checked in a batch of 
thread-related changes on Oct 15; do you have any clue what's going 
wrong here?  I can investigate further if it's not obvious, or somebody 
is not already working on this....

-Sandra

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

[Pedro Alves]

On 10/24/2014 04:54 PM, Sandra Loosemore wrote:
> Yesterday I refreshed my build tree for testing some further nios2 
> patches, and started seeing a whole lot of this in my test results:
> 
> (gdb) target remote qa8-centos32-cs:10514
> Remote debugging using qa8-centos32-cs:10514
> (gdb) set remote hardware-watchpoint-limit 1
> (gdb) set mem inaccessible-by-default on

This made me suspect of 0fec99e8be72b091618862eafc14e2741f0ff0d5,
though I'm not seeing how that'd end up in the error
in question.

> (gdb) load
> Loading section .text, size 0x844 lma 0x10000000
> Loading section .eh_frame, size 0x4 lma 0x10000844
> Loading section .rodata, size 0x120 lma 0x10000848
> Loading section .data, size 0x428 lma 0x10000968
> Start address 0x10000040, load size 3472
> Transfer rate: 41 KB/sec, 868 bytes/write.
> (gdb) continue
> Continuing.
> Cannot execute this command without a live selected thread.
> (gdb) ERROR: couldn't run to breakpoint
> 

Odd.  A backtrace at (break at "error") and "set debug infrun/remote"
logs would probably be revealing.

> I think the checkout I used for testing the last nios2 patch I submitted 
> was a couple weeks old.  Pedro, I see you checked in a batch of 
> thread-related changes on Oct 15; do you have any clue what's going 
> wrong here?  I can investigate further if it's not obvious, or somebody 
> is not already working on this....

Yeah, I pushed in the whole software single-step rework that day.
Might well be related, given this target uses software single-step.

But it's indeed not obvious and it's the first I hear about it.

Thanks,
Pedro Alves

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

[Sandra Loosemore]

[-- Attachment #1: Type: text/plain, Size: 888 bytes --]

On 10/24/2014 10:07 AM, Pedro Alves wrote:
> On 10/24/2014 04:54 PM, Sandra Loosemore wrote:
>> (gdb) load
>> Loading section .text, size 0x844 lma 0x10000000
>> Loading section .eh_frame, size 0x4 lma 0x10000844
>> Loading section .rodata, size 0x120 lma 0x10000848
>> Loading section .data, size 0x428 lma 0x10000968
>> Start address 0x10000040, load size 3472
>> Transfer rate: 41 KB/sec, 868 bytes/write.
>> (gdb) continue
>> Continuing.
>> Cannot execute this command without a live selected thread.
>> (gdb) ERROR: couldn't run to breakpoint
>>
>
> Odd.  A backtrace at (break at "error") and "set debug infrun/remote"
> logs would probably be revealing.

Attached.  It appears that on the GDB side the default thread is in an 
"exited" state when the continue command is processed.  I don't know if 
it's relevant that the remote stub doesn't understand the "Hg" packet?

-Sandra


[-- Attachment #2: gdb-output --]
[-- Type: text/plain, Size: 11348 bytes --]

(gdb) set debug remote 1
(gdb) set debug infrun 1
(gdb) break main
Breakpoint 1 at 0x100002ac: file /home/sandra/examples/croak.c, line 10.
(gdb) target remote qa8-centos32-cs:6789
Remote debugging using qa8-centos32-cs:6789
Sending packet: $qSupported:multiprocess+;qRelocInsn+#2a...Ack
Packet received: QStartNoAckMode+;PacketSize=2000;qXfer:features:read+
Packet qSupported (supported-packets) is supported
Sending packet: $QStartNoAckMode#b0...Ack
Packet received: OK
Sending packet: $Hg0#df...Packet received: 
Sending packet: $qXfer:features:read:target.xml:0,fff#7d...Packet received: l<?xml version="1.0"?><!DOCTYPE target SYSTEM "gdb-target.dtd"><target><xi:include href ="nios2-cpu.xml"/></target>
Sending packet: $qXfer:features:read:nios2-cpu.xml:0,fff#56...Packet received: l<?xml version="1.0"?>\n<!-- Copyright (C) 2012-2014 Free Software Foundation, Inc.\n\n     Copying and distribution of this file, with or without modification,\n     are permitted in any medium without royalty provided the copyright\n     notice and this notice are preserved.  -->\n\n<!DOCTYPE feature SYSTEM "gdb-target.dtd">\n<feature name="org.gnu.gdb.nios2.cpu">\n  <reg name="zero" bitsize="32" type="uint32"/>\n  <reg name="at" bitsize="32" type="uint32"/>\n  <reg name="r2" bitsize="32" type="uint32"/>\n  <reg name="r3" bitsize="32" type="uint32"/>\n  <reg name="r4" bitsize="32" type="uint32"/>\n  <reg name="r5" bitsize="32" type="uint32"/>\n  <reg name="r6" bitsize="32" type="uint32"/>\n  <reg name="r7" bitsize="32" type="uint32"/>\n  <reg name="r8" bitsize="32" type="uint32"/>\n  <reg name="r9" bitsize="32" type="uint32"/>\n  <reg name="r10" bitsize="32" type="uint32"/>\n  <reg name="r11" bitsize="32" type="uint32"/>\n  <reg name="r12" bitsize="32" type="uint32"/>\n  <reg name="r13" bitsize="32" type="uint32"/>\n  <reg name="r14" bitsize="32" type="uint32"/>\n  <reg name="r15" bitsize="32" type="uint32"/>\n  <reg name="r16" bitsize="32" type="uint32"/>\n  <reg name="r17" bitsize="32" type="uint32"/>\n  <reg name="r18" bitsize="32" type="uint32"/>\n  <reg name="r19" bitsize="32" type="uint32"/>\n  <reg name="r20" bitsize="32" type="uint32"/>\n  <reg name="r21" bitsize="32" type="uint32"/>\n  <reg name="r22" bitsize="32" type="uint32"/>\n  <reg name="r23" bitsize="32" type="uint32"/>\n  <reg name="et" bitsize="32" type="uint32"/>\n  <reg name="bt" bitsize="32" type="uint32"/>\n  <reg name="gp" bitsize="32" type="data_ptr"/>\n  <reg name="sp" bitsize="32" type="data_ptr"/>\n  <reg name="fp" bitsize="32" type="data_ptr"/>\n  <reg name="ea" bitsize="32" type="code_ptr"/>\n  <reg name="sstatus" bitsize="32" type="uint32"/>\n  <reg name="ra" bitsize="32" type="code_ptr"/>\n  <reg name="pc" bitsize="32" type="code_ptr"/>\n  <reg name="status" bitsize="32" type="uint32"/>\n  <reg name="estatus" bitsize="32" type="uint32"/>\n  <reg name="bstatus" bitsize="32" type="uint32"/>\n  <reg name="ienable" bitsize="32" type="uint32"/>\n  <reg name="ipending" bitsize="32" type="uint32"/>\n  <reg name="cpuid" bitsize="32" type="uint32"/>\n  <reg name="ctl6" bitsize="32" type="uint32"/>\n  <reg name="exception" bitsize="32" type="uint32"/>\n  <reg name="pteaddr" bitsize="32" type="uint32"/>\n  <reg name="tlbacc" bitsize="32" type="uint32"/>\n  <reg name="tlbmisc" bitsize="32" type="uint32"/>\n  <reg name="eccinj" bitsize="32" type="uint32"/>\n  <reg name="badaddr" bitsize="32" type="uint32"/>\n  <reg name="config" bitsize="32" type="uint32"/>\n  <reg name="mpubase" bitsize="32" type="uint32"/>\n  <reg name="mpuacc" bitsize="32" type="uint32"/>\n</feature>\n
Sending packet: $qTStatus#49...Packet received: 
Packet qTStatus (trace-status) is NOT supported
Sending packet: $?#3f...Packet received: S00
Sending packet: $qfThreadInfo#bb...Packet received: l
Sending packet: $Hc-1#09...Packet received: 
Sending packet: $qC#b4...Packet received: unset
Sending packet: $qAttached#8f...Packet received: 
Packet qAttached (query-attached) is NOT supported
infrun: clear_proceed_status_thread (Thread <main>)
Sending packet: $qOffsets#4b...Packet received: 
infrun: wait_for_inferior ()
infrun: target_wait (-1, status) =
infrun:   42000 [Thread <main>],
infrun:   status->kind = stopped, signal = GDB_SIGNAL_0
infrun: TARGET_WAITKIND_STOPPED
Sending packet: $g#67...Packet received: 0000000044f8ff0708800000088000000000000000000000000000000000000020e30010000000000080000000f8ff07efbeaddeefbeaddeefbeaddeefbeaddeefbeadde00000000efbeaddebcf8ff07efbeaddeefbeaddeefbeaddeefbeaddeefbeadde00000000efbeaddeefbeaddeefbeaddeefbeadde0000000004000010
Sending packet: $p20#d2...Packet received: 00000010
Packet p (fetch-register) is supported
infrun: stop_pc = 0x10000000
infrun: quietly stopped
infrun: stop_waiting
Sending packet: $qfThreadInfo#bb...Packet received: l
Sending packet: $qSymbol::#5b...Packet received: 
Packet qSymbol (symbol-lookup) is NOT supported
(gdb) load
...
Start address 0x10000040, load size 58144
Sending packet: $P20=40000010#74...Packet received: OK
Packet P (set-register) is supported
Transfer rate: 37 KB/sec, 3420 bytes/write.

(gdb) c
Continuing.

Breakpoint 1, error (
    fmt=fmt@entry=0x834d2c8 "Cannot execute this command without a live selected thread.")
    at /scratch/sandra/nios2-elf-fsf/obj/gdb-src-mainline-0-nios2-elf-i686-pc-linux-gnu/gdb/common/errors.c:39
39	{
(gdb) bt
#0  error (
    fmt=fmt@entry=0x834d2c8 "Cannot execute this command without a live selected thread.")
    at /scratch/sandra/nios2-elf-fsf/obj/gdb-src-mainline-0-nios2-elf-i686-pc-linux-gnu/gdb/common/errors.c:39
#1  0x0811ed94 in ensure_valid_thread ()
    at /scratch/sandra/nios2-elf-fsf/obj/gdb-src-mainline-0-nios2-elf-i686-pc-linux-gnu/gdb/infcmd.c:696
#2  0x0812202c in continue_1 (all_threads=all_threads@entry=0)
    at /scratch/sandra/nios2-elf-fsf/obj/gdb-src-mainline-0-nios2-elf-i686-pc-linux-gnu/gdb/infcmd.c:768
#3  0x081221fa in continue_command (args=<optimized out>, from_tty=1)
    at /scratch/sandra/nios2-elf-fsf/obj/gdb-src-mainline-0-nios2-elf-i686-pc-linux-gnu/gdb/infcmd.c:858
#4  0x08202d9a in execute_command (p=<optimized out>, p@entry=0x8472998 "c", 
    from_tty=1)
    at /scratch/sandra/nios2-elf-fsf/obj/gdb-src-mainline-0-nios2-elf-i686-pc-linux-gnu/gdb/top.c:476
#5  0x08141cff in command_handler (command=0x8472998 "c")
    at /scratch/sandra/nios2-elf-fsf/obj/gdb-src-mainline-0-nios2-elf-i686-pc-linux-gnu/gdb/event-top.c:432
#6  0x081426fa in command_line_handler (rl=0x84ece58 "")
    at /scratch/sandra/nios2-elf-fsf/obj/gdb-src-mainline-0-nios2-elf-i686-pc-linux-gnu/gdb/event-top.c:629
#7  0x0824be3a in rl_callback_read_char ()
    at /scratch/sandra/nios2-elf-fsf/obj/gdb-src-mainline-0-nios2-elf-i686-pc-linux-gnu/readline/callback.c:220
#8  0x08141d68 in rl_callback_read_char_wrapper (client_data=0x0)
    at /scratch/sandra/nios2-elf-fsf/obj/gdb-src-mainline-0-nios2-elf-i686-pc-linux-gnu/gdb/event-top.c:166
#9  0x08140ad0 in handle_file_event (data=data@entry=...)
    at /scratch/sandra/nios2-elf-fsf/obj/gdb-src-mainline-0-nios2-elf-i686-pc-linux-gnu/gdb/event-loop.c:762
#10 0x08141088 in process_event ()
    at /scratch/sandra/nios2-elf-fsf/obj/gdb-src-mainline-0-nios2-elf-i686-pc-linux-gnu/gdb/event-loop.c:339
#11 process_event ()
    at /scratch/sandra/nios2-elf-fsf/obj/gdb-src-mainline-0-nios2-elf-i686-pc-linux-gnu/gdb/event-loop.c:311
#12 0x08141424 in gdb_do_one_event ()
    at /scratch/sandra/nios2-elf-fsf/obj/gdb-src-mainline-0-nios2-elf-i686-pc-linux-gnu/gdb/event-loop.c:403
#13 0x08141587 in start_event_loop ()
    at /scratch/sandra/nios2-elf-fsf/obj/gdb-src-mainline-0-nios2-elf-i686-pc-linux-gnu/gdb/event-loop.c:428
#14 0x0813ab58 in current_interp_command_loop ()
    at /scratch/sandra/nios2-elf-fsf/obj/gdb-src-mainline-0-nios2-elf-i686-pc-linux-gnu/gdb/interps.c:317
#15 0x0813b1d2 in captured_command_loop (data=data@entry=0x0)
    at /scratch/sandra/nios2-elf-fsf/obj/gdb-src-mainline-0-nios2-elf-i686-pc-linux-gnu/gdb/main.c:321
#16 0x081388a7 in catch_errors (
    func=func@entry=0x813b1c0 <captured_command_loop>, 
    func_args=func_args@entry=0x0, errstring=errstring@entry=0x830587c "", 
    mask=mask@entry=RETURN_MASK_ALL)
    at /scratch/sandra/nios2-elf-fsf/obj/gdb-src-mainline-0-nios2-elf-i686-pc-linux-gnu/gdb/exceptions.c:237
#17 0x0813be24 in captured_main (data=data@entry=0xffffd964)
    at /scratch/sandra/nios2-elf-fsf/obj/gdb-src-mainline-0-nios2-elf-i686-pc-linux-gnu/gdb/main.c:1149
#18 0x081388a7 in catch_errors (func=func@entry=0x813b7d0 <captured_main>, 
    func_args=func_args@entry=0xffffd964, 
    errstring=errstring@entry=0x830587c "", mask=mask@entry=RETURN_MASK_ALL)
    at /scratch/sandra/nios2-elf-fsf/obj/gdb-src-mainline-0-nios2-elf-i686-pc-linux-gnu/gdb/exceptions.c:237
#19 0x0813c5b7 in gdb_main (args=0xffffd964)
    at /scratch/sandra/nios2-elf-fsf/obj/gdb-src-mainline-0-nios2-elf-i686-pc-linux-gnu/gdb/main.c:1157
#20 0x0804ce9b in main (argc=2, argv=0xffffda24)
    at /scratch/sandra/nios2-elf-fsf/obj/gdb-src-mainline-0-nios2-elf-i686-pc-linux-gnu/gdb/gdb.c:32
(gdb) frame 1
#1  0x0811ed94 in ensure_valid_thread ()
    at /scratch/sandra/nios2-elf-fsf/obj/gdb-src-mainline-0-nios2-elf-i686-pc-linux-gnu/gdb/infcmd.c:696
696	    error (_("Cannot execute this command without a live selected thread."));
(gdb) print inferior_ptid
$1 = {pid = 42000, lwp = -1, tid = 1}
(gdb) print null_ptid
$2 = {pid = 0, lwp = 0, tid = 0}
(gdb) print is_exited (inferior_ptid)
$3 = 1
(gdb) print *find_thread_ptid (inferior_ptid)
$4 = {next = 0x0, ptid = {pid = 42000, lwp = -1, tid = 1}, num = 1, 
  name = 0x0, executing = 0, state = THREAD_EXITED, refcount = 0, control = {
    step_resume_breakpoint = 0x0, exception_resume_breakpoint = 0x0, 
    single_step_breakpoints = 0x0, step_range_start = 0, step_range_end = 0, 
    may_range_step = 0, step_frame_id = {stack_addr = 0, code_addr = 0, 
      special_addr = 0, stack_status = FID_STACK_INVALID, code_addr_p = 0, 
      special_addr_p = 0, artificial_depth = 0}, step_stack_frame_id = {
      stack_addr = 0, code_addr = 0, special_addr = 0, 
      stack_status = FID_STACK_INVALID, code_addr_p = 0, special_addr_p = 0, 
      artificial_depth = 0}, trap_expected = 0, proceed_to_finish = 0, 
    in_infcall = 0, step_over_calls = STEP_OVER_UNDEBUGGABLE, stop_step = 0, 
    stop_bpstat = 0x0, command_interp = 0x0}, suspend = {
    stop_signal = GDB_SIGNAL_0}, current_line = 0, current_symtab = 0x0, 
  prev_pc = 0, stepping_over_breakpoint = 0, stepping_over_watchpoint = 0, 
  step_after_step_resume_breakpoint = 0, continuations = 0x0, 
  intermediate_continuations = 0x0, step_multi = 0, pending_follow = {
    kind = TARGET_WAITKIND_SPURIOUS, value = {integer = 0, sig = GDB_SIGNAL_0, 
      related_pid = {pid = 0, lwp = 0, tid = 0}, execd_pathname = 0x0, 
      syscall_number = 0}}, stop_requested = 0, initiating_frame = {
    stack_addr = 0, code_addr = 0, special_addr = 0, 
    stack_status = FID_STACK_INVALID, code_addr_p = 0, special_addr_p = 0, 
    artificial_depth = 0}, private = 0x8508ad0, 
  private_dtor = 0x8051830 <free_private_thread_info>, btrace = {target = 0x0, 
    begin = 0x0, end = 0x0, level = 0, flags = 0, insn_history = 0x0, 
    call_history = 0x0, replay = 0x0}}
(gdb) 

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

[Pedro Alves]

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?

> Sending packet: $Hc-1#09...Packet received: 
> Sending packet: $qC#b4...Packet received: unset

Thanks,
Pedro Alves

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

[Pedro Alves]

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.  */
-- 
1.9.3

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

[Sandra Loosemore]

On 10/24/2014 11:40 AM, Pedro Alves wrote:
> On 10/24/2014 06:23 PM, Pedro Alves wrote:
>>
>> 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.

The patch works fine for hand-testing of a hello world program (can load 
and run it and stop at breakpoint on main, at least).  I've kicked off a 
full set of tests.

-Sandra

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

[Doug Evans]

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?

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

[Pedro Alves]

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

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

[Doug Evans]

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.

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

[Pedro Alves]

On 10/24/2014 09:02 PM, Doug Evans wrote:
> 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.

All process_stratum targets do.  remote.c is a process_stratum
target, and I think that last to be converted:

commit ba3481708d3f18e77ab6c000385b131c76d2733e
Author:     Pedro Alves <palves@redhat.com>
AuthorDate: Wed Feb 19 18:25:40 2014 +0000
Commit:     Pedro Alves <palves@redhat.com>
CommitDate: Wed Feb 19 18:25:40 2014 +0000

    remote.c: Use the ptid.lwp field to store remote thread ids rather than ptid.tid.

    From GDB's perspective, independently of how the target really
    implements threads, gdb/remote sees all threads as if kernel/system
    threads.  A rationale along theses lines led to gdbserver storing
    thread ids in ptid.lwp in all ports.

    Because remote.c is currently using ptid.tid, we can't make gdbserver
    and gdb share bits of remote-specific code that manipulates ptids
    (e.g., write_ptid/read_ptid).

    This patch thus makes remote.c use ptid.lwp instead of ptid.tid.

    I believe that on the GDB side too, it's best that we standardize on
    process_stratum targets using the ptid.lwp field to store thread ids
    anyway.  The idea being leave the ptid.tid field free for any
    thread_stratum target that might want to sit on top.

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

Not sure what you mean by "support" here.

Thanks,
Pedro Alves

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

[Doug Evans]

Pedro Alves writes:
 > > Not all targets use ptid.lwp.
 > 
 > All process_stratum targets do.

windows-nat.c doesn't
(at least I remember seeing all calls to ptid_build there
passing 0 for lwp).
Could be missing something of course.

 >     I believe that on the GDB side too, it's best that we standardize on
 >     process_stratum targets using the ptid.lwp field to store thread ids
 >     anyway.  The idea being leave the ptid.tid field free for any
 >     thread_stratum target that might want to sit on top.

The language in the comment in ptid.h waffles a bit:

   process_stratum targets that handle threading themselves should
   prefer using the ptid.lwp field, leaving the ptid.tid field for any
   thread_stratum target that might want to sit on top.

Can we make this more of a rule than just a "should prefer"?
[and fix targets to follow]

Remove libthread_db -> remove thread_stratum? [was Re: Cannot execute this command without a live selected thread.]

[Doug Evans]

[note subject change]

Doug Evans writes:
 > Pedro Alves writes:
 >  > > Not all targets use ptid.lwp.
 >  > 
 >  > All process_stratum targets do.
 > 
 > windows-nat.c doesn't
 > (at least I remember seeing all calls to ptid_build there
 > passing 0 for lwp).
 > Could be missing something of course.
 > 
 >  >     I believe that on the GDB side too, it's best that we standardize on
 >  >     process_stratum targets using the ptid.lwp field to store thread ids
 >  >     anyway.  The idea being leave the ptid.tid field free for any
 >  >     thread_stratum target that might want to sit on top.
 > 
 > The language in the comment in ptid.h waffles a bit:
 > 
 >    process_stratum targets that handle threading themselves should
 >    prefer using the ptid.lwp field, leaving the ptid.tid field for any
 >    thread_stratum target that might want to sit on top.
 > 
 > Can we make this more of a rule than just a "should prefer"?
 > [and fix targets to follow]

Oh, btw, another question I've been wanting to ask ...

One goal we have is to remove libthread_db on linux.
There are two reasons we still have it, pthread_t and thread local vars,
though those can be solved.

Long term, at least in linux-land,
do we still want to keep thread_stratum?
Knowing the answer to this will help save some typing.
[If one did want to remove thread_stratum for linux
there's still a need to support older systems.
But on future newer systems without libthread_db,
what would thread_stratum look like?]

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

[Pedro Alves]

On 10/24/2014 09:38 PM, Doug Evans wrote:
> Pedro Alves writes:
>  > > Not all targets use ptid.lwp.
>  > 
>  > All process_stratum targets do.
> 
> windows-nat.c doesn't
> (at least I remember seeing all calls to ptid_build there
> passing 0 for lwp).
> Could be missing something of course.

Eh, I was quite sure I once wrote a patch for that, and
I thought I had pushed it, but I can't find it now.

Ah, back in 2008 I went through all targets migrating
away from storing the thread in ptid_t.pid.

commit 2dc38344f418c9abe65755308ef6db836a61103a
Author:     Pedro Alves <palves@redhat.com>

        Use ptid_t.tid to store thread ids instead of ptid_t.pid.

        * win32-nat.c (win32_add_thread): Change thread argument type to

etc.  That made way for the multi-process support in the core
being able to rely on ptid_t.pid.

It was much later (years) that I realized that ptid.lwpid would
be a better field.

Anyway, should be a trivial change.  Nothing outside the target
should be looking at ptid.lwpid vs ptid.tid.  I fixed gnu-nat.c
and remote.c recently, but I now see that nto-procfs.c, remote-sim.c
and darwin-nat.c still haven't been given the treatment.
I got confused with wishful thinking.  :-P

> 
>  >     I believe that on the GDB side too, it's best that we standardize on
>  >     process_stratum targets using the ptid.lwp field to store thread ids
>  >     anyway.  The idea being leave the ptid.tid field free for any
>  >     thread_stratum target that might want to sit on top.
> 
> The language in the comment in ptid.h waffles a bit:
> 
>    process_stratum targets that handle threading themselves should
>    prefer using the ptid.lwp field, leaving the ptid.tid field for any
>    thread_stratum target that might want to sit on top.
> 
> Can we make this more of a rule than just a "should prefer"?
> [and fix targets to follow]

Sure, guess I didn't use a stronger word at the time because
I hadn't yet forgotten that the all-targets conversion wasn't
finished.  :-)

Thanks,
Pedro Alves

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

[Sandra Loosemore]

On 10/24/2014 11:40 AM, Pedro Alves wrote:
>
> 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.

This worked for me.  The remaining ERRORs in the nios2-elf test results 
are due to the GCC switch to C11.

-Sandra

[pushed] Workaround remote targets that report an empty list to qfThreadInfo (Re: Cannot execute this command without a live selected thread.)

[Pedro Alves]

On 10/27/2014 07:53 PM, Sandra Loosemore wrote:
> On 10/24/2014 11:40 AM, Pedro Alves wrote:
>>
>> 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.
> 
> This worked for me.  The remaining ERRORs in the nios2-elf test results 
> are due to the GCC switch to C11.

Thanks Sandra, now pushed.

From 7d1a114c44db3d7055afe48868f939ba95a64b7b Mon Sep 17 00:00:00 2001
From: Pedro Alves <palves@redhat.com>
Date: Tue, 28 Oct 2014 11:35:10 +0000
Subject: [PATCH] Workaround remote targets that report an empty list to
 qfThreadInfo

In https://sourceware.org/ml/gdb-patches/2014-10/msg00652.html, Sandra
shows a target that was broken by the recent update_thread_list
optimization:

 (gdb) target remote qa8-centos32-cs:10514
 ...
 (gdb) continue
 Continuing.
 Cannot execute this command without a live selected thread.
 (gdb)

The error means that the current thread is in "exited" state when the
continue command is processed.  The root of the problem was found
here:

 > Sending packet: $Hg0#df...Packet received:
 ...
 > Sending packet: $?#3f...Packet received: S00
 > Sending packet: $qfThreadInfo#bb...Packet received: l
 > Sending packet: $Hc-1#09...Packet received:
 > Sending packet: $qC#b4...Packet received: unset

This target doesn't really support threads (no thread indication in
stop reply packets; no support for qC), but then supports
qfThreadInfo, and returns an empty thread list to GDB.

See https://sourceware.org/ml/gdb-patches/2014-10/msg00665.html for
why the target does that.

As remote_update_thread_list deletes threads from GDB's list that are
not found in the thread list that the target reports, the result is
that GDB deletes the "fake" main thread that GDB added itself.  (As
that thread is currently selected, it is marked "exited" instead of
being deleted straight away.)

This commit avoids deleting the main thread in this scenario.

gdb/
2014-10-27  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/ChangeLog |  8 ++++++++
 gdb/remote.c  | 35 ++++++++++++++++++++++++++++++++---
 2 files changed, 40 insertions(+), 3 deletions(-)

diff --git a/gdb/ChangeLog b/gdb/ChangeLog
index 8a34118..b358dd7 100644
--- a/gdb/ChangeLog
+++ b/gdb/ChangeLog
@@ -1,5 +1,13 @@
 2014-10-27  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.
+
+2014-10-27  Pedro Alves  <palves@redhat.com>
+
 	* infrun.c (handle_signal_stop): Also skip handlers when a random
 	signal arrives while handling a "stepi" or a "nexti".  Set the
 	thread's 'step_after_step_resume_breakpoint' flag.
diff --git a/gdb/remote.c b/gdb/remote.c
index 20f2988..4b9b099 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.  */
-- 
1.9.3

Re: [pushed] Workaround remote targets that report an empty list to qfThreadInfo (Re: Cannot execute this command without a live selected thread.)

[Doug Evans]

On Tue, Oct 28, 2014 at 5:09 AM, Pedro Alves <palves@redhat.com> wrote:
> On 10/27/2014 07:53 PM, Sandra Loosemore wrote:
>> On 10/24/2014 11:40 AM, Pedro Alves wrote:
>>>
>>> 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.
>>
>> This worked for me.  The remaining ERRORs in the nios2-elf test results
>> are due to the GCC switch to C11.
>
> Thanks Sandra, now pushed.

Hi.

I was going to send the email appended at the bottom out,
but since the Subject line didn't specify a patch intended to be committed,
"[PATCH] mumble ..." or some such,
I didn't want to violate protocol.

>
> From 7d1a114c44db3d7055afe48868f939ba95a64b7b Mon Sep 17 00:00:00 2001
> From: Pedro Alves <palves@redhat.com>
> Date: Tue, 28 Oct 2014 11:35:10 +0000
> Subject: [PATCH] Workaround remote targets that report an empty list to
>  qfThreadInfo
>
> In https://sourceware.org/ml/gdb-patches/2014-10/msg00652.html, Sandra
> shows a target that was broken by the recent update_thread_list
> optimization:
>
>  (gdb) target remote qa8-centos32-cs:10514
>  ...
>  (gdb) continue
>  Continuing.
>  Cannot execute this command without a live selected thread.
>  (gdb)
>
> The error means that the current thread is in "exited" state when the
> continue command is processed.  The root of the problem was found
> here:
>
>  > Sending packet: $Hg0#df...Packet received:
>  ...
>  > Sending packet: $?#3f...Packet received: S00
>  > Sending packet: $qfThreadInfo#bb...Packet received: l
>  > Sending packet: $Hc-1#09...Packet received:
>  > Sending packet: $qC#b4...Packet received: unset
>
> This target doesn't really support threads (no thread indication in
> stop reply packets; no support for qC), but then supports
> qfThreadInfo, and returns an empty thread list to GDB.
>
> See https://sourceware.org/ml/gdb-patches/2014-10/msg00665.html for
> why the target does that.
>
> As remote_update_thread_list deletes threads from GDB's list that are
> not found in the thread list that the target reports, the result is
> that GDB deletes the "fake" main thread that GDB added itself.  (As
> that thread is currently selected, it is marked "exited" instead of
> being deleted straight away.)
>
> This commit avoids deleting the main thread in this scenario.
>
> gdb/
> 2014-10-27  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/ChangeLog |  8 ++++++++
>  gdb/remote.c  | 35 ++++++++++++++++++++++++++++++++---
>  2 files changed, 40 insertions(+), 3 deletions(-)
>
> diff --git a/gdb/ChangeLog b/gdb/ChangeLog
> index 8a34118..b358dd7 100644
> --- a/gdb/ChangeLog
> +++ b/gdb/ChangeLog
> @@ -1,5 +1,13 @@
>  2014-10-27  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.
> +
> +2014-10-27  Pedro Alves  <palves@redhat.com>
> +
>         * infrun.c (handle_signal_stop): Also skip handlers when a random
>         signal arrives while handling a "stepi" or a "nexti".  Set the
>         thread's 'step_after_step_resume_breakpoint' flag.
> diff --git a/gdb/remote.c b/gdb/remote.c
> index 20f2988..4b9b099 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.  */
> --
> 1.9.3
>
>


---snip---
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.

Hi.

I don't have an opinion on whether to patch gdb, the stub, or both,
but if this patch does indeed address the issue and goes in
a few comments.  :-)

I realize this was just a suggestion for Sandra to try,
but if it works it's not clear there'll be a follow-on formal patch.

 > >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 ...

Typo: remote_thread_always_alive.

 >      (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)
 >  {

The function comment and function name leave me the reader confused.

IOW: Which is it? Is it
(a) Return nonzero if this is the main thread that we made up ourselves,
or
(b) Return nonzero if the thread is always alive.

To the reader it's not clear the two are synonymous
and will remain so.  Call sites also conflate the two
concepts.

Any rewording of the comment to clear things up would suffice.

E.g.,
/* Return nonzero if thread PTID is always alive.
   E.g., If this is the main thread that we made up ourselves
   to model non-threaded targets as single-threaded.  */
[or some such]

Plus the function also has this test:

  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;

which isn't a made-up thread.

Another possibility is changing the name to something like
remote_ptid_is_main_thread or some such.
I guess I prefer the former though.
---snip---

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

[Sandra Loosemore]

On 10/24/2014 11:23 AM, 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?

I dug around in the svn history for our stub library.   We made that 
change to the thread packet handling because if it returned an empty 
response to qfThreadInfo instead, GDB persistently complained:

warning: RMT ERROR : failed to get remote thread list.

especially when being run from Eclipse.

It seemed then that debugging worked OK in spite of the warnings, but 
the messages looked both frightening and incomprehensible to users. 
This was back in 2010, so maybe GDB doesn't do that any more.

-Sandra

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

[Pedro Alves]

On 10/24/2014 06:56 PM, Sandra Loosemore wrote:

> I dug around in the svn history for our stub library.   We made that 
> change to the thread packet handling because if it returned an empty 
> response to qfThreadInfo instead, GDB persistently complained:
> 
> warning: RMT ERROR : failed to get remote thread list.
> 
> especially when being run from Eclipse.
> 
> It seemed then that debugging worked OK in spite of the warnings, but 
> the messages looked both frightening and incomprehensible to users. 
> This was back in 2010, so maybe GDB doesn't do that any more.

Ah, yes, that rang a bell.  Vladimir fixed it in GDB, in 2010:

  https://sourceware.org/ml/gdb-patches/2010-10/msg00293.html

Thanks,
Pedro Alves