Created attachment 7708 [details] testcase Seems like it may be too soon to enable asynchronous by default for remote targets, at least in all-stop mode. bash1$ gdbserver --once :1234 forever-threads.x64 bash2$ gdb forever-threads.x64 (gdb) tar rem :1234 (gdb) b all_threads_running (gdb) c [breakpoint hit] (gdb) c & (gdb) q A debugging session is active. Inferior 1 [process 29047] will be killed. Quit anyway? (y or n) y Cannot execute this command while the target is running. (gdb) k Kill the program being debugged? (y or n) y Cannot execute this command while the target is running. (gdb) Ouch. In all-stop nothing can (currently) be sent to gdbserver until the program stops. remote.c:putpkt_binary: /* Catch cases like trying to read memory or listing threads while we're waiting for a stop reply. The remote server wouldn't be ready to handle this request, so we'd hang and timeout. We don't have to worry about this in synchronous mode, because in that case it's not possible to issue a command while the target is running. This is not a problem in non-stop mode, because in that case, the stub is always ready to process serial input. */ if (!non_stop && target_can_async_p () && rs->waiting_for_stop_reply) error (_("Cannot execute this command while the target is running."));
I marked this as a blocker for 7.8 to make sure this gets looked at before 7.8 is released. I'm not sure yet how best to fix this (in the release or in trunk).
If the user uses only the features she could use before 7.8, nothing changes, and target-async is completely transparent. It's only if you use features you couldn't before (c&) that you get into that situation. And then, you _could_ get into this situation before too, just not by default (with "set target-async on" before 7.8). So it doesn't look like a regression or a 7.8 blocker to me. Though of course not being able to quit (without interrupting the target first) is never nice.
Although, in the before case one had to manually enable it first or one would get an error. Now one doesn't get an error - just a completely hosed session.
One thought would be to print a message either with commands that resume the inferior in the background, or with the "Cannot execute this command while the target is running." error message. E.g. Cannot execute this command while the target is running. Use the "interrupt" command to stop the target. or perhaps a teensy bit better, Cannot execute this command while the target is running. Use the "interrupt" command to stop the target and then try again. [side note: why does "interrupt -a" have to be an error in all-stop mode? Instead just treat "interrupt -a" == "interrupt". Filed bug 17160.]
Re. message: yeah, that'd be fine with me.
I think a doc update is also required. The doc refers to execution commands only, however with gdbserver one can't even do things like "info threads" until the target stops. ---snip--- Background execution is especially useful in conjunction with non-stop mode for debugging programs with multiple threads; see @ref{Non-Stop Mode}. However, you can also use these commands in the normal all-stop mode with the restriction that you cannot issue another execution command until the previous one finishes. Examples of commands that are valid in all-stop mode while the program is running include @code{help} and @code{info break}. ---snip---
This is an automated email from the git hooks/post-receive script. It was generated because a ref change was pushed to the repository containing the project "gdb and binutils". The branch, master has been updated via 9597b22adf3552a5617d73104d8facd6a7aea881 (commit) from 91101fe524e5ae8a912880bf3350ad93d511181a (commit) Those revisions listed above that are new to this repository have not appeared on any other notification email; so we list those revisions in full, below. - Log ----------------------------------------------------------------- https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;h=9597b22adf3552a5617d73104d8facd6a7aea881 commit 9597b22adf3552a5617d73104d8facd6a7aea881 Author: Doug Evans <dje@google.com> Date: Sun Jul 20 15:36:23 2014 -0700 Improve error message to cope with pr 17147. PR server/17147 * remote.c (putpkt_binary): Add text to error message. ----------------------------------------------------------------------- Summary of changes: gdb/ChangeLog | 5 +++++ gdb/remote.c | 6 +++++- 2 files changed, 10 insertions(+), 1 deletions(-)
This is an automated email from the git hooks/post-receive script. It was generated because a ref change was pushed to the repository containing the project "gdb and binutils". The branch, gdb-7.8-branch has been updated via 933f5a202ed484a2d727d0bfc7a38f2983e18646 (commit) from 40bf817af867e1c601da9a16fd158eca1351dad9 (commit) Those revisions listed above that are new to this repository have not appeared on any other notification email; so we list those revisions in full, below. - Log ----------------------------------------------------------------- https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;h=933f5a202ed484a2d727d0bfc7a38f2983e18646 commit 933f5a202ed484a2d727d0bfc7a38f2983e18646 Author: Doug Evans <dje@google.com> Date: Sun Jul 20 15:42:02 2014 -0700 Improve error message to cope with pr 17147. PR server/17147 * remote.c (putpkt_binary): Add text to error message. ----------------------------------------------------------------------- Summary of changes: gdb/ChangeLog | 5 +++++ gdb/remote.c | 6 +++++- 2 files changed, 10 insertions(+), 1 deletions(-)