From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 57678 invoked by alias); 10 Sep 2015 10:20:18 -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 57662 invoked by uid 89); 10 Sep 2015 10:20:16 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.4 required=5.0 tests=AWL,BAYES_00,KAM_LAZY_DOMAIN_SECURITY,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 10:20:15 +0000 Received: from int-mx09.intmail.prod.int.phx2.redhat.com (int-mx09.intmail.prod.int.phx2.redhat.com [10.5.11.22]) by mx1.redhat.com (Postfix) with ESMTPS id 27CDD8C1D0; Thu, 10 Sep 2015 10:20:13 +0000 (UTC) Received: from [127.0.0.1] (ovpn01.gateway.prod.ext.ams2.redhat.com [10.39.146.11]) by int-mx09.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id t8AAKCok023430; Thu, 10 Sep 2015 06:20:12 -0400 Message-ID: <55F1595B.1050206@redhat.com> Date: Thu, 10 Sep 2015 10:20: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: qemu-system debugging broken ([PATCH 03/18] remote.c/all-stop: Implement TARGET_WAITKIND_NO_RESUMED and TARGET_WNOHANG) References: <55DF8CFB.2060204@codesourcery.com> In-Reply-To: <55DF8CFB.2060204@codesourcery.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-SW-Source: 2015-09/txt/msg00151.txt.bz2 Hi Luis, Sorry, I was away last week, and am still catching up. On 08/27/2015 11:19 PM, Luis Machado wrote: > Just a heads-up. It looks like this particular commit... > > commit 567420d10895611e03d5ee65e6b24c16a69a6e99 > Author: Pedro Alves > Date: Fri Aug 7 17:23:56 2015 +0100 > > remote.c/all-stop: Implement TARGET_WAITKIND_NO_RESUMED and > TARGET_WNOHANG > > Even though "target remote" supports target-async, the all-stop > target_wait implementation ignores TARGET_WNOHANG. If the core > happens to poll for events and we've already read the stop reply out > of the serial/socket, remote_wait_as hangs forever instead of > returning an indication that there are no events to process. This > can't happen currently, but later changes will trigger this. > > gdb/ChangeLog: > 2015-08-07 Pedro Alves > > * remote.c (remote_wait_as): If not waiting for a stop reply, > return TARGET_WAITKIND_NO_RESUMED. If TARGET_WNOHANG is > requested, don't block waiting forever. > > ... broke simulator-based debugging. The following is what i get when > trying to run the gdb.base/break binary on qemu-system for arm eabi: > > _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 > 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 > 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 > 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. > > Upon further inspection, it looks like the setting of status->kind to > TARGET_WAITKIND_NO_RESUMED in remote_wait_as causes GDB to stop waiting > for events and marks the active thread as running, returning the GDB > prompt and printing the old familiar message. > > Without setting TARGET_WAITKIND_NO_RESUMED, things worked fine and the > binary runs to completion, like so: ... > It sounds like we shouldn't drop to the prompt while we wait for > something to happen in all-stop mode either. Yes, but if the target was resumed, how come rs->waiting_for_stop_reply was false? if (!rs->waiting_for_stop_reply) { status->kind = TARGET_WAITKIND_NO_RESUMED; return minus_one_ptid; } I suspect that what happens is that qemu sends an F packet, and we miss setting waiting_for_stop_reply true back, like we do in the other cases: gdb/remote:remote_wait_as () { ... /* We got something. */ rs->waiting_for_stop_reply = 0; ... case 'F': /* File-I/O request. */ remote_fileio_request (buf, rs->ctrlc_pending_p); rs->ctrlc_pending_p = 0; break; ... Looks like it'd be simpler to instead only clear waiting_for_stop_reply in the stop reply cases, instead of re-setting it in some cases, forgetting others. Thanks, Pedro Alves