From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 87793 invoked by alias); 19 Sep 2016 10:17:27 -0000 Mailing-List: contact gdb-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sourceware.org Received: (qmail 87780 invoked by uid 89); 19 Sep 2016 10:17:26 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-4.0 required=5.0 tests=BAYES_00,KAM_LAZY_DOMAIN_SECURITY,RP_MATCHES_RCVD,SPF_HELO_PASS autolearn=ham version=3.3.2 spammy=constantly, Somehow, Hx-languages-length:2930, Nonstop 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 ESMTP; Mon, 19 Sep 2016 10:17:25 +0000 Received: from int-mx10.intmail.prod.int.phx2.redhat.com (int-mx10.intmail.prod.int.phx2.redhat.com [10.5.11.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 833DE319B73; Mon, 19 Sep 2016 10:17:24 +0000 (UTC) Received: from [127.0.0.1] (ovpn01.gateway.prod.ext.ams2.redhat.com [10.39.146.11]) by int-mx10.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id u8JAHN5J004962; Mon, 19 Sep 2016 06:17:23 -0400 Subject: Re: Non-stop mode for Windows (mingw) To: Raphael Zulliger , "gdb@sourceware.org" References: <45100db8-5b69-6a7a-e6cc-bad09e686f46@indel.ch> From: Pedro Alves Message-ID: <9bd24124-be7c-2257-7518-8cba0345e195@redhat.com> Date: Mon, 19 Sep 2016 10:17:00 -0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 In-Reply-To: <45100db8-5b69-6a7a-e6cc-bad09e686f46@indel.ch> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-SW-Source: 2016-09/txt/msg00055.txt.bz2 On 09/19/2016 07:25 AM, Raphael Zulliger wrote: > According to empirical tests and by looking at the GDB sources, > 'windows-nat.c' and, therefore, GDB running on Windows (mingw) does not > support non-stop debugging. > > - What's the technical reason behind this? Was it just not ported to > that platform so far? This. > Wasn't it done because it's tricky? - What would be needed to support it? First, implement "maint set target-async on" support. That is, support background execution commands, like "continue&", even in all-stop mode. non-stop mode requires target-async support. This basically means two things: #1 - Implement support for TARGET_WNOHANG in windows_wait, returning TARGET_WAITKIND_IGNORE when there's no event to process. The easiest is to return TARGET_WAITKIND_IGNORE when WaitForDebugEvent times out. We currently loop locally instead. #2 - Somehow wake up gdb's main event loop whenever there's a target event to process. The easiest though least efficient way would be constantly force the event loop to poll, by always calling mark_async_event_handler when windows_wait is called. Essentially, telling the event loop code that there's maybe some event to process. If there's no actually event to return, then #1 above kicks in. You'd probably want to avoid the large time out inside windows_nat though. So I'd try passing 0 as time out time to WaitForDebugEvent, to effect a real poll, and then use the event loop's timer events support to poll at some frequency instead of constantly. To avoid the polling you'd probably need to move the WaitForDebugEvent calls to a separate thread. You'd then install a waitable event in gdb's event loop, which the WaitForDebugEvent thread would set. You'd use serial_event for this (gdb/ser-event.h), which is basically a thin wrapper around SetEvent. Then for non-stop, you'll want to support debugging one stopped thread while the others are left running. The main problem I think is that WaitForDebugEvent implicitly suspends all threads. In principle, it might be possible to SuspendThread the event thread and call ContinueDebugEvent immediately after WaitForDebugEvent returns the event. First change exception handling and DBG_CONTINUE / DBG_EXCEPTION_NOT_HANDLED is an open question then though. > (Is the main required thing that > 'displaced single stepping' is required for non-stop mode?) No. Non-stop can work correctly without that nowadays -- gdb pauses all threads, removes a breakpoint, step the thread over the breakpoint, and then re-resumes threads that were originally running. So displaced stepping is considered an optimization nowadays, rather than a requirement. In any case, the displaced stepping implementation is mostly architecture-specific, rather than OS specific, so the x86 Windows port just needs to wire in the existing x86 displaced stepping support. Thanks, Pedro Alves