This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
Re: [PATCH, doc RFA]: Fix pr 14236
- From: Doug Evans <dje at google dot com>
- To: gdb-patches at sourceware dot org
- Date: Mon, 7 Jul 2014 09:08:50 -0700
- Subject: Re: [PATCH, doc RFA]: Fix pr 14236
- Authentication-results: sourceware.org; auth=none
- References: <yjt261mvjqar dot fsf at ruffy dot mtv dot corp dot google dot com> <21305 dot 45035 dot 310308 dot 253836 at ruffy dot mtv dot corp dot google dot com>
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.