From patchwork Fri Aug 28 00:58:18 2015 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Luis Machado X-Patchwork-Id: 8492 Received: (qmail 120311 invoked by alias); 28 Aug 2015 00:58:34 -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 120298 invoked by uid 89); 28 Aug 2015 00:58:33 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.3 required=5.0 tests=AWL, BAYES_00, KAM_LOTSOFHASH, RCVD_IN_DNSWL_LOW, SPF_PASS autolearn=ham version=3.3.2 X-HELO: relay1.mentorg.com Received: from relay1.mentorg.com (HELO relay1.mentorg.com) (192.94.38.131) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Fri, 28 Aug 2015 00:58:31 +0000 Received: from svr-orw-fem-06.mgc.mentorg.com ([147.34.97.120]) by relay1.mentorg.com with esmtp id 1ZV7zw-0006lT-Je from Luis_Gustavo@mentor.com for gdb-patches@sourceware.org; Thu, 27 Aug 2015 17:58:28 -0700 Received: from opsys.world.mentorg.com (147.34.91.1) by SVR-ORW-FEM-06.mgc.mentorg.com (147.34.97.120) with Microsoft SMTP Server id 14.3.224.2; Thu, 27 Aug 2015 17:58:27 -0700 From: Luis Machado To: Subject: [PATCH] Make GDB wait for events after handling target File-I/O Date: Thu, 27 Aug 2015 21:58:18 -0300 Message-ID: <1440723498-19075-1-git-send-email-lgustavo@codesourcery.com> MIME-Version: 1.0 X-IsSubscribed: yes GDB was not behaving correctly with qemu-system debugging: _ftext () at arm-vector.S:25 25 ldr pc, [pc, #24] @ reset (gdb) load Loading section .text, size 0xc01c lma 0x0 Loading section .eh_frame, size 0x48 lma 0xc01c Loading section .ARM.exidx, size 0x8 lma 0xc064 Loading section .rodata, size 0x398 lma 0xc070 Loading section .data, size 0x8e0 lma 0xc408 Start address 0x40, load size 52452 Transfer rate: 17074 KB/sec, 1748 bytes/write. (gdb) c Continuing. infrun: clear_proceed_status_thread (Thread 1) infrun: proceed (addr=0xffffffff, signal=GDB_SIGNAL_DEFAULT) infrun: resume (step=0, signal=GDB_SIGNAL_0), trap_expected=0, current thread [Thread 1] at 0x40 Sending packet: $vCont?#49...Ack Packet received: Packet vCont (verbose-resume) is NOT supported Sending packet: $Hc0#db...Ack Packet received: OK Sending packet: $c#63...Ack infrun: infrun_async(1) infrun: prepare_to_wait infrun: target_wait (-1.0.0, status) = infrun: -1.0.0 [Thread 0], infrun: status->kind = ignore infrun: TARGET_WAITKIND_IGNORE infrun: prepare_to_wait Packet received: Ffstat,00000001,07fffdb0 Sending packet: $M7fffdb0,40:000000000000000000002080000000010000c336000001180000000000000000000000000000000000000200000000000000000055dfb11b55dfb11b55dfb11b#5a...Ack Packet received: OK Sending packet: $F0#76...Ack infrun: target_wait (-1.0.0, status) = infrun: -1.0.0 [Thread 0], infrun: status->kind = ignore infrun: TARGET_WAITKIND_IGNORE infrun: prepare_to_wait infrun: target_wait (-1.0.0, status) = infrun: -1.0.0 [Thread 0], infrun: status->kind = no-resumed infrun: TARGET_WAITKIND_NO_RESUMED infrun: stop_waiting infrun: clear_step_over_info Sending packet: $qfThreadInfo#bb...Ack Packet received: m1 Sending packet: $qsThreadInfo#c8...Ack Packet received: l No unwaited-for children left. infrun: infrun_async(0) (gdb) c Continuing. Cannot execute this command while the selected thread is running. (gdb) Continuing. Cannot execute this command while the selected thread is running. This behavior shows up whenever GDB is in all-stop mode and is handling target-initiated File-I/O requests, in the middle of, say, a continue request. When GDB is done handling the File-I/O request, it doesn't set rs->waiting_for_stop_reply back to 1, meaning GDB should wait for further target events. This seems to be a latent bug, because in the past this didn't really cause any issues. But it seems to have been uncovered by commit 567420d10895611e03d5ee65e6b24c16a69a6e99, which explicitly checks for rs->waiting_for_stop_reply == 0, triggering the failures above. The following patch fixes this by setting rs->waiting_for_stop_reply back to 1 after handling the target-initiated File-I/O request. infrun: prepare_to_wait Packet received: Ffstat,00000001,07fffdb0 Sending packet: $M7fffdb0,40:000000000000000000002080000000010000c336000001180000000000000000000000000000000000000200000000000000000055dfb19e55dfb19e55dfb19e#7b...Ack Packet received: OK Sending packet: $F0#76...Ack infrun: target_wait (-1.0.0, status) = infrun: -1.0.0 [Thread 0], infrun: status->kind = ignore infrun: TARGET_WAITKIND_IGNORE infrun: prepare_to_wait Packet received: Fisatty,00000001 Sending packet: $F1#77...Ack infrun: target_wait (-1.0.0, status) = infrun: -1.0.0 [Thread 0], infrun: status->kind = ignore infrun: TARGET_WAITKIND_IGNORE infrun: prepare_to_wait Packet received: Fwrite,00000001,0000d098,00000004 Sending packet: $md098,4#d2...Ack Packet received: 3732300a 720 Sending packet: $F4#7a...Ack infrun: target_wait (-1.0.0, status) = infrun: -1.0.0 [Thread 0], infrun: status->kind = ignore infrun: TARGET_WAITKIND_IGNORE infrun: prepare_to_wait Packet received: Fwrite,00000001,07ffffac,00000011 Sending packet: $m7ffffac,11#8e...Ack Packet received: 0a2a2a2a204558495420636f646520300a *** EXIT code 0 Regression-tested on Ubuntu x86-64 and qemu-system-based debugging for arm eabi. OK? gdb/ChangeLog: 2015-08-27 Luis Machado * remote.c (remote_wait_as): Reset rs->waiting_for_stop_reply to 1 after handling File-I/O. --- gdb/remote.c | 4 ++++ 1 file changed, 4 insertions(+) diff --git a/gdb/remote.c b/gdb/remote.c index 3afcaf4..31e67a9 100644 --- a/gdb/remote.c +++ b/gdb/remote.c @@ -6486,6 +6486,10 @@ remote_wait_as (ptid_t ptid, struct target_waitstatus *status, int options) case 'F': /* File-I/O request. */ 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 'T': case 'S': case 'X': case 'W': {