From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 104715 invoked by alias); 10 Sep 2015 12:59: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 104696 invoked by uid 89); 10 Sep 2015 12:59:56 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.2 required=5.0 tests=AWL,BAYES_00,KAM_LAZY_DOMAIN_SECURITY,KAM_LOTSOFHASH,SPF_HELO_PASS,T_RP_MATCHES_RCVD autolearn=no version=3.3.2 X-HELO: mx1.redhat.com Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES256-GCM-SHA384 encrypted) ESMTPS; Thu, 10 Sep 2015 12:59:55 +0000 Received: from int-mx11.intmail.prod.int.phx2.redhat.com (int-mx11.intmail.prod.int.phx2.redhat.com [10.5.11.24]) by mx1.redhat.com (Postfix) with ESMTPS id 9BBE12F02B0; Thu, 10 Sep 2015 12:59:54 +0000 (UTC) Received: from [127.0.0.1] (ovpn01.gateway.prod.ext.ams2.redhat.com [10.39.146.11]) by int-mx11.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id t8ACxqw7005252; Thu, 10 Sep 2015 08:59:53 -0400 Message-ID: <55F17EC8.5010906@redhat.com> Date: Thu, 10 Sep 2015 12:59:00 -0000 From: Pedro Alves User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: Luis Machado , gdb-patches@sourceware.org Subject: Re: [PATCH] Make GDB wait for events after handling target File-I/O References: <1440723498-19075-1-git-send-email-lgustavo@codesourcery.com> In-Reply-To: <1440723498-19075-1-git-send-email-lgustavo@codesourcery.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-SW-Source: 2015-09/txt/msg00162.txt.bz2 On 08/28/2015 01:58 AM, Luis Machado wrote: > 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? This is OK. Though I'd prefer if we removed the: /* We got something. */ rs->waiting_for_stop_reply = 0; line, and then cleared waiting_for_stop_reply in both the case 'E': case 'T': case 'S': case 'X': case 'W': cases. That'd make the check for waiting_for_stop_reply in interrupt_query work correctly while inside remote_console_output too: case 'O': /* Console output. */ remote_console_output (buf + 1); /* The target didn't really stop; keep waiting. */ rs->waiting_for_stop_reply = 1; Thanks, Pedro Alves