gdb in non-stop/sync mode connects to gdbserver

[Yao Qi <yao at codesourcery dot com>]

Hello,
When running moribund-step.exp with boardfile 'unix', we'll get two passes,

  PASS: gdb.base/moribund-step.exp: set non-stop on
  PASS: gdb.base/moribund-step.exp: step

However, when running it with boardilfe native-gdbserver, we'll get only 
one pass,

  PASS: gdb.base/moribund-step.exp: set non-stop on

in fact, gdb hang there when connecting to gdbserver.  Supposing gdb is 
in non-stop and sync mode, here is callgraph of functions related to 
'connecting to remote gdbserver'.

remote_start_remote
  1) putpkt ("QNonStop:1");
  2) remote_thread_info
       |
       +-> remote_notice_new_inferior
             |
             +-> notice_new_inferior
             |     |
             |     +-> target_stop and then wait_for_inferior [A]
             +-> attach_command_post_wait
                   |
                   + target_stop (in non-stop mode, and no wait) [B]

 3) putpkt ("?")
 4) init_wait_for_inferior
 5) check packet replied to "?", and handle stop reply if needed.

After step 1), GDBserver knows that "we are in non-stop mode".  In step 
2), gdb calls target_stop in [A], sending 'vCont;t' to stop one thread, 
and expect to get a %Stop notification.  However, when gdbserver 
launches program, the thread has been stopped before gdb connects to 
gdbserver.  So the stop request from gdb is ignored by gdbserver (shown 
by the gdbserver log below),

  getpkt ("vCont;t:p45df.45df");  [no ack sent]
  already stopped LWP 17887 at GDB's request
  Need step over [LWP 17887]? Ignoring, should remain stopped
  Resuming, no pending status or step over needed
  putpkt ("$OK#9a"); [noack mode]

and no %Stop notification is sent back to gdb.  Then, gdb hang there.

The problem is that gdb wants to get a certain thread stopped, but 
doesn't know its state, so has to blindly force to stop it, and expect a 
%Stop notification to come.  Then, I am wondering if gdbserver can sends 
the state of threads, if known, to gdb when gdb connects, and gdb don't 
have to stop threads if they are already stopped.  Is it a good way to 
go?  We can achieve this by add new attribute 'state' in the xml 
returned to qxfer:threads:read.  My experiments show it works, but not 
sure if I miss something important.

Doing this is not enough to fix the problem I mentioned at the 
beginning.  There is another problem in the following steps.  Supposing 
gdb doesn't call target_stop in [A], gdb will call target_stop in [B],

      GDB            GDBserver
[B]   'vCont;t'  ->
                 <- 'OK'
3)    '?'        ->
                 <- 'T0505:xxxxx'
4)
5) process stop reply and send 'vStopped'
     'vStopped'  ->
                 <- 'OK'

This process requires that there is no packet sent in step 4), because 
gdb is expecting to get a stop reply.  Unfortunately, 
breakpoint_init_inferior, called by init_wait_for_inferior, has to 
access inferior memory, so 'm' packet is sent out.  Looks like the fix 
to this problem is to move all functions which cause sending packets in 
step 4) after step 5).  Does it sound a good idea?

I've got a patch to fix the two problems, but I am not sure it is on a 
right direction.  If it is correct, I'll polish the patch, and post it.

--
Yao (éå)