gdb7.2 - remote target - non-stop, multi-thread, target-async - non "OK" response, why?

[Daniel Lehne <daniel dot lehne at amk-drives dot bg>]

Hello,

I've compiled newest version gdb 7.2 for target - arm1136jfs(armv6) - 
and try to run the following debug session. On the target machine runs 
the gdbserver on the host an eclipse with gdb.

Debug session:
The main program contains source to load shared libraries by a 
configuration file. So a linking time they are not known, but after 
occurring in memory, gdb automatically detects them and set possible 
breakpoints in there.
The shared library, i want to debug, is called by this program and 
contains multi-threads of type pthread. Some of this threads are rising 
up the priority, higher than gdbserver, shell and other program running 
on linux - arm.

1. Without non-stop, target-async settings, the debug session tries in 
stepping mode after breakpoint to synchronize all threads of the 
complete program for each step. Actual more than 10 threads are 
generated by the shared library. Much more threads are generated, much 
harder the gdb could synchronize them. I think this is a normal behavior 
of gdb to debug mult-thread application in synchronized mode. Isn't it?

So i switched to target-async, pagination and non-stop settings.

2. In this mode the debug session aborts already at the first breakpoint 
of main with the the following message:

" Unexpected vCont reply in non-stop mode: 
T050b:44ebc9be;0d:c8e9c9be;0f:bcec0040;thread:p33d.33d;core:0;"

This is from remote.c of gdb:
  if (non_stop)
    {
      /* In non-stop, the stub replies to vCont with "OK".  The stop
         reply will be reported asynchronously by means of a `%Stop'
         notification.  */
      getpkt (&rs->buf, &rs->buf_size, 0);
      if (strcmp (rs->buf, "OK") != 0)
        error (_("Unexpected vCont reply in non-stop mode: %s"), rs->buf);
    }

 When enabling debut remote setting the following transfer is recorded:
Sending packet: $vCont;c:p33d.33d#14...Packet received: 
T050b:44ebc9be;0d:c8e9c9be;0f:bcec0040;thread:p33d.33d;core:0;
The response should be "OK" and not a "T:xxx", or? This is confirmed in 
http://comments.gmane.org/gmane.comp.gdb.devel/29335

Why the gdbserver is not handling this in server.c
/* Parse vCont packets.  */
void
handle_v_cont (char *own_buf)
{
... should handle if ?!
 if (non_stop)
    write_ok (own_buf);
else

... and not this
}
It should be set because, such an error i couldn't seen.
server.c
/* Handle all of the extended 'Q' packets.  */

static void
handle_general_set (char *own_buf)
{

...
      req_str = req ? "non-stop" : "all-stop";
      if (start_non_stop (req) != 0)
        {
          fprintf (stderr, "Setting %s mode failed\n", req_str);
          write_enn (own_buf);
          return;
        }

      non_stop = req;
...
}

Thanks for help!

Best regards!

--
Daniel Lehne,
Dep. Development

AMK Drives and Controls Ltd.
Bulgaria / Gabrovo