This is the mail archive of the mailing list for the GDB project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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


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

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

... and not this
It should be set because, such an error i couldn't seen.
/* 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);

      non_stop = req;

Thanks for help!

Best regards!

Daniel Lehne,
Dep. Development

AMK Drives and Controls Ltd.
Bulgaria / Gabrovo

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]