This is the mail archive of the
mailing list for the GDB project.
gdb7.2 - remote target - non-stop, multi-thread, target-async - non "OK" response, why?
- From: Daniel Lehne <daniel dot lehne at amk-drives dot bg>
- To: gdb at sourceware dot org
- Date: Thu, 30 Jun 2011 09:59:02 +0300
- Subject: 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.
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:
This is from remote.c of gdb:
/* In non-stop, the stub replies to vCont with "OK". The stop
reply will be reported asynchronously by means of a `%Stop'
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:
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 ?!
... and not this
It should be set because, such an error i couldn't seen.
/* Handle all of the extended 'Q' packets. */
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);
non_stop = req;
Thanks for help!
AMK Drives and Controls Ltd.
Bulgaria / Gabrovo