From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 11923 invoked by alias); 7 Jul 2014 16:08:57 -0000 Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org Received: (qmail 11889 invoked by uid 89); 7 Jul 2014 16:08:56 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-3.2 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_LOW,RP_MATCHES_RCVD,SPF_PASS autolearn=ham version=3.3.2 X-HELO: mail-ob0-f202.google.com Received: from mail-ob0-f202.google.com (HELO mail-ob0-f202.google.com) (209.85.214.202) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES128-SHA encrypted) ESMTPS; Mon, 07 Jul 2014 16:08:53 +0000 Received: by mail-ob0-f202.google.com with SMTP id va2so948477obc.1 for ; Mon, 07 Jul 2014 09:08:52 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:mime-version:content-type :content-transfer-encoding:message-id:date:to:subject:in-reply-to :references; bh=gLq1pxyDYvKcztvPGSOl6LfHlzwNtkLu6vRHbUGKtRI=; b=LTfIpfCQIiYu/NNeADW1x9XXNUqLBMFyDBtH3sIyf1QkXw+hUyzkAimh3KNBx82u2I gL3MdX58WjxawRIL7O3HdTRP+wYZAUroegDm29aDdm++V1zGuKkMq9ffPwG7LcXjqE0f DiRCznQlXoGa+ftU8wQXfG3iq1tkDqfw7AxwTV26zwohQRueJE98ZJmUd2HusX6uKt9x yahtfxzbXIMnQ+hF0W04BD240Ouqs20IdHUmBshNjS0LQbHkwyoPacVdO0bmnAVnEXyS kyHYXVQalNpLVPn/pTfVjj7+meJSpRck68hjNDojqfFDWjBMJghC6MpAQcLlw+VlBAE4 HEKw== X-Gm-Message-State: ALoCoQnLQKdAJkqDu7W24F5c3QJbS8RQblPS7YARWG5Ryde3gUQdYzbrS1dAzFOsGE67MUmSSwNlpqF4UH8HfprikbiAau3s9Zi4mscroM18EC6S5/EDc8b3BNI+/044qin32+3Nn8LI X-Received: by 10.42.209.140 with SMTP id gg12mr14979206icb.26.1404749331940; Mon, 07 Jul 2014 09:08:51 -0700 (PDT) Received: from corp2gmr1-1.hot.corp.google.com (corp2gmr1-1.hot.corp.google.com [172.24.189.92]) by gmr-mx.google.com with ESMTPS id j43si2333203yhh.5.2014.07.07.09.08.51 for (version=TLSv1.1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Mon, 07 Jul 2014 09:08:51 -0700 (PDT) Received: from ruffy.mtv.corp.google.com (ruffy.mtv.corp.google.com [172.17.128.44]) by corp2gmr1-1.hot.corp.google.com (Postfix) with ESMTP id 8336931C6C8 for ; Mon, 7 Jul 2014 09:08:51 -0700 (PDT) From: Doug Evans MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <21434.50706.899640.768621@ruffy.mtv.corp.google.com> Date: Mon, 07 Jul 2014 16:08:00 -0000 To: gdb-patches@sourceware.org Subject: Re: [PATCH, doc RFA]: Fix pr 14236 In-Reply-To: <21305.45035.310308.253836@ruffy.mtv.corp.google.com> References: <21305.45035.310308.253836@ruffy.mtv.corp.google.com> X-IsSubscribed: yes X-SW-Source: 2014-07/txt/msg00125.txt.bz2 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 > > 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.