This is the mail archive of the
gdb-prs@sourceware.org
mailing list for the GDB project.
[Bug gdb/14236] Cannot continue in background with target-async after interrupting
- From: "xdje42 at gmail dot com" <sourceware-bugzilla at sourceware dot org>
- To: gdb-prs at sourceware dot org
- Date: Sun, 30 Mar 2014 21:03:00 +0000
- Subject: [Bug gdb/14236] Cannot continue in background with target-async after interrupting
- Auto-submitted: auto-generated
- References: <bug-14236-4717 at http dot sourceware dot org/bugzilla/>
https://sourceware.org/bugzilla/show_bug.cgi?id=14236
Doug Evans <xdje42 at gmail dot com> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |xdje42 at gmail dot com
--- Comment #3 from Doug Evans <xdje42 at gmail dot com> ---
Now that I have a patch that works (from a user's perspective) the way I want
it to, I've found three testcases that assume an implicit "&":
gdb.base/
async-shell.exp
dprintf-non-stop.exp
interrupt-noterm.exp
Another way to look at this, obviously, is to not expect the "interrupt"
command to wait, and have a separate "wait" command. I think we want a
separate wait command, regardless. However, that doesn't mean the current
design of interrupt isn't broken.
Alas, adding "&" to "interrupt", and changing the default behaviour to wait,
*could* break existing code.
Another way to do is to add a "-w" command to interrupt to mean "wait".
All that would mean is that one could type
interrupt -a -w
instead of
interrupt -a
wait -a
The latter, however, opens up a source of confusion if the user types
interrupt -a
wait
With my user's hat on I'd expect that when I see the gdb prompt after doing
"interrupt -a" all threads are in fact stopped. I'm working on the above
alternatives, but for now I'm going to see what the community thinks of adding
& to "interrupt".
--
You are receiving this mail because:
You are on the CC list for the bug.