Non-stop attach misses stopped events

[Marc Khouzam <marc dot khouzam at ericsson dot com>]

Hi,

I got a bug report on Eclipse that I believe I can 'blame' on GDB :-)

When using the 'attach' command to attach to a process in non-stop mode
on Linux, all threads are stopped automatically, but only the first
thread reports a *stopped event.  So Eclipse reports all but one
thread as running, when they are actually all stopped.
I will need to work around this for Eclipse, but I still think
it would be nice to fix GDB.

GDB session below showing this.

I believe I tracked it down to the logic in 
infcmd.c#attach_command_post_wait()
where it says:

      /* At least the current thread is already stopped.  */

      /* In all-stop, by definition, all threads have to be already
	 stopped at this point.  In non-stop, however, although the
	 selected thread is stopped, others may still be executing.
                                  ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
	 Be sure to explicitly stop all threads of the process.  This
	 should have no effect on already stopped threads.  */
      if (non_stop)
	  target_stop (pid_to_ptid (inferior->pid));

So the problem is that _all_ threads are already stopped, unlike
what the comment suggests, and therefore we don't force a stop
on any threads, and don't see any *stopped events (except the
default one).

Here are the options I'm thinking of:

1- have the attach procedure somehow trigger normal_stop() for 
each thread, which will eventually cause the *stopped event.
That seems intrusive, and very low-level.

2- have the single *stopped event report "all" as the stopped
thread list.  I like this, but I'm not sure it is possible
to tell the MI code that even in non-stop, it should use
the "all" tag for just this case.

3- actually resume all threads (like when doing an async attach
('attach&')) and then stop all of them again.  This is very
easy, and it makes Eclipse work well, but it causes extra
*running events, and feels like a hack.

I can submit a patch for option 3 if that does seem like a way
forward.

Any opinions?

Thanks


Session
=======
> gdb -i mi
=thread-group-added,id="i1"
~"GNU gdb (GDB) 7.2.50.20101222-cvs\n"
(gdb) set target-async on
&"set target-async on\n"
^done
(gdb) set non-stop on
&"set non-stop on\n"
^done
(gdb) attach 5285

=== This inferior has two threads ===

&"attach 5285\n"
~"Attaching to process 5285\n"
=thread-group-started,id="i1",pid="5285"
=thread-created,id="1",group-id="i1"
^done
(gdb) 
~"Reading symbols from /home/lmckhou/runtime-TestDSF/QuickTests/Debug/QuickTests..."
~"done.\n"
=library-loaded,id="/lib/tls/i686/cmov/libpthread.so.0",target-name="/lib/tls/i686/cmov/libpthread.so.0",host-name="/lib/tls/i686/cmov/libpthread.so.0",symbols-loaded="0",thread-group="i1"
[...]
~"Reading symbols from /lib/tls/i686/cmov/libpthread.so.0..."
~"(no debugging symbols found)...done.\n"
~"[Thread debugging using libthread_db enabled]\n"
=thread-created,id="2",group-id="i1"
~"[New Thread 0xb7863b70 (LWP 5286)]\n"
~"Loaded symbols for /lib/tls/i686/cmov/libpthread.so.0\n"
~"Reading symbols from /usr/lib/libstdc++.so.6..."
~"(no debugging symbols found)...done.\n"
[...]
*stopped,frame={addr="0x0034e422",func="__kernel_vsyscall",args=[]},thread-id="1",stopped-threads=["1"],core="1"

=== only one *stopped event, and it is for the first thread ===
=== notice also the missing (gdb) prompt and ^done, but that is probably another issue ===

-list-thread-groups i1
^done,threads=[{id="2",target-id="Thread 0xb7863b70 (LWP 5286)",
frame={level="0",addr="0x0034e422",func="__kernel_vsyscall",args=[]},state="stopped",core="0"},
{id="1",target-id="Thread 0xb7865b30 (LWP 5285)",
frame={level="0",addr="0x0034e422",func="__kernel_vsyscall",args=[]},state="stopped",core="1"}]

=== Both threads are actually stopped ===