From patchwork Fri Jan 29 10:49:06 2016 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Yao Qi X-Patchwork-Id: 10666 Received: (qmail 26115 invoked by alias); 29 Jan 2016 10:49:17 -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 24208 invoked by uid 89); 29 Jan 2016 10:49:15 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.5 required=5.0 tests=AWL, BAYES_00, FREEMAIL_FROM, RCVD_IN_DNSWL_LOW, SPF_PASS autolearn=ham version=3.3.2 spammy=1500, 6997, 167, 1037 X-HELO: mail-pf0-f174.google.com Received: from mail-pf0-f174.google.com (HELO mail-pf0-f174.google.com) (209.85.192.174) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES128-GCM-SHA256 encrypted) ESMTPS; Fri, 29 Jan 2016 10:49:14 +0000 Received: by mail-pf0-f174.google.com with SMTP id 65so40402219pfd.2 for ; Fri, 29 Jan 2016 02:49:14 -0800 (PST) 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; bh=tBp6o7LknOdf+rQ5XJSNu3TFKpS9SpymvlrS0DRZ5Gw=; b=GDBFmd/Dl7NX4rhnbazPJCokIJ16sXJwUtywv7EfuUewfP58oyBWFmEzjlyfuANI0P PYIITTeqRlSwxOWZqH5BolidgX6h9VDrgSP1lSKscHQ3vJ+EuV2qLXXs9VB39rjm0qsH LXHZ02D3CrhxrWiAciooA9Up38YgzNmo+MTpNZYyvxISdfrYriSpsFwDONQdKOIniO6o OO8cIUxOhW4qO2hQSQhnLt4vZcdTQsmgOGoztpHkVtFBPeVn9pbG35KoIFUDYEBmZxQL 1UxeYlD6N+InVnh9ZLVj5ZVGmUVeIGuB4HnqaaDdqbasxnvZeW7EGjjEucNYTgkmEtHk 0VLw== X-Gm-Message-State: AG10YOTKPs3nFbr/TgZr0fbB1EyusKjIiCoBlKUD0oTffaAihJCNOVjVZLJIdy9Q7usYxA== X-Received: by 10.98.80.135 with SMTP id g7mr12355043pfj.132.1454064552187; Fri, 29 Jan 2016 02:49:12 -0800 (PST) Received: from E107787-LIN.cambridge.arm.com (gcc1-power7.osuosl.org. [140.211.15.137]) by smtp.gmail.com with ESMTPSA id 74sm18508131pfs.33.2016.01.29.02.49.10 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Fri, 29 Jan 2016 02:49:11 -0800 (PST) From: Yao Qi X-Google-Original-From: Yao Qi To: gdb-patches@sourceware.org Subject: [PATCH] waiting_for_stop_reply around remote_fileio_request Date: Fri, 29 Jan 2016 10:49:06 +0000 Message-Id: <1454064546-4419-1-git-send-email-yao.qi@linaro.org> X-IsSubscribed: yes Hi, I see this error when GDB works with qemu, (gdb) n .... Sending packet: $vCont;c#a8...Ack Packet received: Ffstat,00000001,f6fff038 Cannot execute this command while the target is running. Use the "interrupt" command to stop the target and then try again. looks we don't set rs->waiting_for_stop_reply to zero before handle fileio request, #10 0x00000000005edb64 in target_write (len=64, offset=4143968312, buf=0x7fffffffd570 "\375\377\377\377", annex=0x0, object=TARGET_OBJECT_MEMORY, ops=) at /home/yao/SourceCode/gnu/gdb/git/gdb/target.c:1922 #11 target_write_memory (memaddr=memaddr@entry=4143968312, myaddr=myaddr@entry=0x7fffffffd6a0 "", len=len@entry=64) at /home/yao/SourceCode/gnu/gdb/git/gdb/target.c:1500 #12 0x00000000004b2b41 in remote_fileio_func_fstat (buf=0x127b258 "") at /home/yao/SourceCode/gnu/gdb/git/gdb/remote-fileio.c:1037 #13 0x00000000004b1878 in do_remote_fileio_request (uiout=, buf_arg=buf_arg@entry=0x127b240) at /home/yao/SourceCode/gnu/gdb/git/gdb/remote-fileio.c:1204 #14 0x00000000005b8c7c in catch_exceptions_with_msg (func_uiout=, func=func@entry=0x4b1800 , func_args=func_args@entry=0x127b240, gdberrmsg=gdberrmsg@entry=0x0, mask=mask@entry=RETURN_MASK_ALL) at /home/yao/SourceCode/gnu/gdb/git/gdb/exceptions.c:187 #15 0x00000000005b8dea in catch_exceptions (uiout=, func=func@entry=0x4b1800 , func_args=func_args@entry=0x127b240, mask=mask@entry=RETURN_MASK_ALL) at /home/yao/SourceCode/gnu/gdb/git/gdb/exceptions.c:167 #16 0x00000000004b2fff in remote_fileio_request (buf=0x127b240 "Xf6fff038,0:", ctrlc_pending_p=0) at /home/yao/SourceCode/gnu/gdb/git/gdb/remote-fileio.c:1255 #17 0x0000000000496f12 in remote_wait_as (ptid=..., status=0x7fffffffdb20, options=1) at /home/yao/SourceCode/gnu/gdb/git/gdb/remote.c:6997 however, we did set rs->waiting_for_stop_reply to zero before Luis's patch https://sourceware.org/ml/gdb-patches/2015-10/msg00336.html In fact, Luis's patch v1 https://sourceware.org/ml/gdb-patches/2015-08/msg00809.html is about setting rs->waiting_for_stop_reply back to one after remote_fileio_request, which is correct. However during the review, the patch is changed and ends up with "not setting rs->waiting_for_stop_reply to zero". I manually test GDB, but I don't have a way to run regression tests. gdb: 2016-01-29 Yao Qi * remote.c (remote_wait_as): Set rs->waiting_for_stop_reply to 0 before handling 'F' and set it back afterwards. --- gdb/remote.c | 8 ++++++++ 1 file changed, 8 insertions(+) diff --git a/gdb/remote.c b/gdb/remote.c index d5701e3..f396a8f 100644 --- a/gdb/remote.c +++ b/gdb/remote.c @@ -6994,8 +6994,16 @@ remote_wait_as (ptid_t ptid, struct target_waitstatus *status, int options) status->value.sig = GDB_SIGNAL_0; break; case 'F': /* File-I/O request. */ + /* GDB may access the inferior memory while handling the File-I/O + request, but we don't want it GDB accessing memory while waiting + for a stop reply. See the comments in putpkt_binary. Set + waiting_for_stop_reply to 0 temporarily. */ + rs->waiting_for_stop_reply = 0; remote_fileio_request (buf, rs->ctrlc_pending_p); rs->ctrlc_pending_p = 0; + /* GDB handled the File-I/O request, but the target is running + again. Keep waiting for events. */ + rs->waiting_for_stop_reply = 1; break; case 'N': case 'T': case 'S': case 'X': case 'W': {