This is the mail archive of the gdb-patches@sourceware.org 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]

Re: [PATCH, doc RFA]: Fix pr 14236


Doug Evans writes:
 > Doug Evans writes:
 >  > Hi.
 >  > 
 >  > This patch is a proposed(!) fix to bug 14236.
 >  > The problem here is that the "interrupt" command (figuratively speaking)
 >  > takes an implicit & as an argument (it is always asynchronous) and
 >  > users aren't expecting this.
 >  > 
 >  > This patch fixes the problem by changing the behaviour by making
 >  > "interrupt" synchronous by default and supporting a new option &,
 >  > to be consistent with every other gdb command (which is what I think
 >  > every user would expect, including this user).
 >  > 
 >  > Alas, while I think this is the correct fix (*1), if one could set aside
 >  > breaking existing code, the latter, obviously, is important too.
 >  > I had to update a few testcases that expected the old behaviour,
 >  > but I don't, in this particular case, have a feel for whether the
 >  > change in behaviour would break anything outside of gdb's testsuite.
 >  > Without a "wait" command the current behaviour is completely useless
 >  > in scripts, for example.
 >  > 
 >  > I have patches in the works to fix this in other ways.
 >  > E.g., regardless of how "interrupt" is fixed I think we also want a
 >  > "wait" command.
 >  > 
 >  > But for now I'd like to know what the community thinks of this approach.
 >  > 
 >  > (*1): gdb's infrun state machine doesn't support waiting for all
 >  > threads to stop in non-stop mode, AFAICT, and I'm loathe to make it more
 >  > complicated just to handle this.  Therefore the continuation that handles
 >  > completing the interrupt command waits for any remaining threads itself.
 >  > Alas, I'm not sure if there's a technical reason why this patch
 >  > can't work.  It is derived, in part, from the attach support, and it
 >  > too waits for threads outside of the main event loop.
 > 
 > Hi.  Sorry for the followup.
 > Gotta love test-driven-development.
 > I had a TODO of another testcase and sure enough ...
 > 
 > This patch replaces the previous one.
 > No doc changes, just a new testcase and a change to wait
 > for the current thread to stop in non-stop mode.
 > 
 > 2014-03-30  Doug Evans  <xdje42@gmail.com>
 > 
 > 	PR gdb/14236
 > 	* NEWS: Mention change in default behaviour of "interrupt" command.
 > 	* infcmd.c (struct interrupt_command_continuation_args): New struct.
 > 	(interrupt_command_continuation_free_args): New function.
 > 	(wait_thread_stopped): New function.
 > 	(interrupt_command_post_wait): New function.
 > 	(interrupt_command_continuation): New function.
 > 	(add_interrupt_continuation): New function.
 > 	(interrupt_command): Rewrite.
 > 
 > 	doc/
 > 	* gdb.texinfo (Background Execution): Document new option "&" for
 > 	"interrupt" command.
 > 
 > 	testsuite/
 > 	* gdb.base/async-shell.exp: Add "&" to "interrupt" command.
 > 	* gdb.base/dprintf-non-stop.exp: Ditto.
 > 	* gdb.base/interrupt-noterm.exp: Ditto.
 > 	* gdb.threads/interrupt-command.c: New file.
 > 	* gdb.threads/interrupt-command.exp: New file.

Hi.
It's been three months.
If there are no comments I will press ahead with this.
The existing asynchronous behaviour of "interrupt" without an "&" is a bug worth fixing IMO.

I can certainly make the new functionality dependent on some flag, if people think it's worth preserving the broken behaviour as the default.


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