This is the mail archive of the
gdb-prs@sourceware.org
mailing list for the GDB project.
[Bug threads/19426] in non-stop mode, gdb should sometimes select the stopping thread
- From: "palves at redhat dot com" <sourceware-bugzilla at sourceware dot org>
- To: gdb-prs at sourceware dot org
- Date: Thu, 21 Jan 2016 17:47:49 +0000
- Subject: [Bug threads/19426] in non-stop mode, gdb should sometimes select the stopping thread
- Auto-submitted: auto-generated
- References: <bug-19426-4717 at http dot sourceware dot org/bugzilla/>
https://sourceware.org/bugzilla/show_bug.cgi?id=19426
--- Comment #3 from Pedro Alves <palves at redhat dot com> ---
Also, if you do a foreground command, then when something causes a stop, and
that results in giving back the prompt to the user, I'm thinking that gdb
should select the thread that stopped. That's why I was speaking in terms of
"giving back the prompt".
Also, I think GDB should _not_ switch the thread to the one that stopped
all-stop mode, when the last command was a background one, for the same reasons
we don't do it in non-stop mode.
All this would merge non-stop and all-stop further. Note that with the
direction suggested in the previous comment, the difference is that in
non-stop, with "continue", I get:
"resume current thread" + "wait for current thread to stop".
and in all-stop, I get:
"resume all threads" + "wait for any thread stop".
So basically the resumption command sets the interpreter to wait for any of the
threads resumed by the last synchronous command (and perhaps their children).
--
You are receiving this mail because:
You are on the CC list for the bug.