From patchwork Thu Jul 17 11:21:28 2014 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Doug Evans X-Patchwork-Id: 2098 Received: (qmail 13892 invoked by alias); 17 Jul 2014 11:21:33 -0000 Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Unsubscribe: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org Delivered-To: mailing list gdb-patches@sourceware.org Received: (qmail 13846 invoked by uid 89); 17 Jul 2014 11:21:32 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.9 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-pa0-f74.google.com Received: from mail-pa0-f74.google.com (HELO mail-pa0-f74.google.com) (209.85.220.74) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES128-SHA encrypted) ESMTPS; Thu, 17 Jul 2014 11:21:30 +0000 Received: by mail-pa0-f74.google.com with SMTP id lj1so588595pab.1 for ; Thu, 17 Jul 2014 04:21:29 -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:to:subject:date:message-id:mime-version :content-type; bh=AIRT9se1QNshCZd32zoaLNyBReXksYtlOCmUwZcb0Q8=; b=DwN6bXJb6C5JIcsFGcRL9bc+/w+hpPN2fa6YuQd8ksb4KZUrrEkcttQHTlJBkdA09b A4khe0c0+YYS+RbXzwmT7cPsCeJhxq7xVQ1qUmDWYKHl5VM+tGm+zti0mwODGBsFIT5B Pejma3hLyzRWJGr+KmxR7GZaNwb/OiJJpW5Mm55I6uAcaQjH1/yvfpQ9CEZqQ2fj2UXP YrvSI5rzieJGVzAEX0V2SgwI/I72/2S0d9i43bqOz3Zn1Kj6i6b5LIvFyJVXuoyuP4y2 oX/AVv9nQl9+6Tl7B9w+QmpfJ/bs991LX/vcqJe1BnH9qGptwDjdVSF4oAczjhAnckYQ /8Ow== X-Gm-Message-State: ALoCoQl6pOx0O1ireiDVmluo2KvidlWNXRvbnuB3DTAuTpRiTEvdiZ+FVv5D0TZ34D46XfExhMmB X-Received: by 10.66.227.229 with SMTP id sd5mr14095429pac.7.1405596089232; Thu, 17 Jul 2014 04:21:29 -0700 (PDT) Received: from corp2gmr1-2.hot.corp.google.com (corp2gmr1-2.hot.corp.google.com [172.24.189.93]) by gmr-mx.google.com with ESMTPS id v44si232448yhv.0.2014.07.17.04.21.29 for (version=TLSv1.1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Thu, 17 Jul 2014 04:21:29 -0700 (PDT) Received: from ruffy.mtv.corp.google.com (ruffy.mtv.corp.google.com [172.17.128.44]) by corp2gmr1-2.hot.corp.google.com (Postfix) with ESMTP id 9E0AF5A42AF; Thu, 17 Jul 2014 04:21:28 -0700 (PDT) From: Doug Evans To: gdb-patches@sourceware.org, palves@redhat.com Subject: [PATCH] PR 17147: Help user cope with running target Date: Thu, 17 Jul 2014 04:21:28 -0700 Message-ID: MIME-Version: 1.0 X-IsSubscribed: yes Hi. PR 17147 is about the user now being able to do, e.g., "c &" without having to explicitly enable it, and then, tripping over some remaining issues. In all-stop mode with gdbserver no further commands can be done before the target stops, even "kill" and "quit" are unusable. bash1$ gdbserver --once :1234 forever-threads.x64 bash2$ gdb forever-threads.x64 (gdb) tar rem :1234 (gdb) b all_threads_running (gdb) c [breakpoint hit] (gdb) c & (gdb) q A debugging session is active. Inferior 1 [process 29047] will be killed. Quit anyway? (y or n) y Cannot execute this command while the target is running. (gdb) k Kill the program being debugged? (y or n) y Cannot execute this command while the target is running. (gdb) [the forever-threads testcase is filed with the pr] While this isn't a regression per se, the fact that async is now enabled by default might make the user wonder why one still has to "interrupt" the target first before doing anything else ("Why doesn't this work better?"). This patch addresses the issue by giving the user instructions on what to do. I think there is still a bug here, one shouldn't have to first stop the target before one can exit gdb, but I think this is sufficient for 7.8. 2014-07-17 Doug Evans PR server/17147 * remote.c (putpkt_binary): Add text to error message. diff --git a/gdb/remote.c b/gdb/remote.c index 76efefa..29c03bc 100644 --- a/gdb/remote.c +++ b/gdb/remote.c @@ -7149,7 +7149,11 @@ putpkt_binary (char *buf, int cnt) running. This is not a problem in non-stop mode, because in that case, the stub is always ready to process serial input. */ if (!non_stop && target_can_async_p () && rs->waiting_for_stop_reply) - error (_("Cannot execute this command while the target is running.")); + { + error (_("Cannot execute this command while the target is running.\n" + "Use the \"interrupt\" command to stop the target\n" + "and then try again.")); + } /* We're sending out a new packet. Make sure we don't look at a stale cached response. */