From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 48190 invoked by alias); 16 May 2017 08:52:09 -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 38786 invoked by uid 89); 16 May 2017 08:45:56 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.4 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_LOW,RCVD_IN_SORBS_SPAM autolearn=ham version=3.3.2 spammy=shipping, road X-HELO: sasl.smtp.pobox.com Received: from pb-smtp2.pobox.com (HELO sasl.smtp.pobox.com) (64.147.108.71) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Tue, 16 May 2017 08:45:53 +0000 Received: from sasl.smtp.pobox.com (unknown [127.0.0.1]) by pb-smtp2.pobox.com (Postfix) with ESMTP id 3D6AD80AC2 for ; Tue, 16 May 2017 04:45:53 -0400 (EDT) Received: from pb-smtp2.nyi.icgroup.com (unknown [127.0.0.1]) by pb-smtp2.pobox.com (Postfix) with ESMTP id 35AC080AC1 for ; Tue, 16 May 2017 04:45:53 -0400 (EDT) Received: from mail-io0-f172.google.com (unknown [209.85.223.172]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by pb-smtp2.pobox.com (Postfix) with ESMTPSA id A848680AC0 for ; Tue, 16 May 2017 04:45:52 -0400 (EDT) Received: by mail-io0-f172.google.com with SMTP id f102so88930299ioi.2 for ; Tue, 16 May 2017 01:45:52 -0700 (PDT) X-Gm-Message-State: AODbwcDnfjDAeu9KYqJcrZWCwmejr39tNOxEsBmylpKlq0xpXhWhnUSq s73vETc+v9C1ehsp84g0icWL36wWpg== X-Received: by 10.107.147.86 with SMTP id v83mr10337823iod.233.1494924352098; Tue, 16 May 2017 01:45:52 -0700 (PDT) MIME-Version: 1.0 Received: by 10.107.53.214 with HTTP; Tue, 16 May 2017 01:45:11 -0700 (PDT) In-Reply-To: <4c77fe53-dafc-3376-6f00-21e69289e39e@redhat.com> References: <4c77fe53-dafc-3376-6f00-21e69289e39e@redhat.com> From: Jonah Graham Date: Tue, 16 May 2017 08:52:00 -0000 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: new-ui and Windows To: Pedro Alves Cc: gdb@sourceware.org Content-Type: text/plain; charset="UTF-8" X-Pobox-Relay-ID: 1198E2BE-3A14-11E7-92C2-61520C78B957-18936988!pb-smtp2.pobox.com X-IsSubscribed: yes X-SW-Source: 2017-05/txt/msg00008.txt.bz2 On 15 May 2017 at 23:49, Pedro Alves wrote: > On 05/15/2017 01:38 PM, Jonah Graham wrote: Thanks Pedro and Eli. I now have good information to get started on this. > The original focus was on GNU/Linux. Even though I/we kept the > idea of supporting Windows down the road in mind, we knew there'd > likely be more work required to get there. > > WinPTY takes care of the Windows console<->pty bridging for "free", > fortunately, which I think means we're mostly there. AFAICT the current Eclipse CDT support for PTY (based on an older version of WinPTY) works well for the CLI connection. Upgrading WinPTY in CDT would be a nice to have, especially if we run into problems. >> The new-ui attempts to open a tty with >> top.c:open_terminal_stream() which calls open(). On Windows, AFAIK, >> this can only open a normal file. > > What kind of file would you like to pass to gdb? My original idea > was that on Windows you'd pass down the path to a bidirectional/duplex > named pipe, and things would Just Work (TM). Doesn't open() work on > such named pipe paths? If not, then the "struct serial" abstraction > seems to know about named pipes already (ser-mingw.c), so maybe it'd work > to adjust the new-ui code to use serial_open instead. > > If other kinds of files are more convenient, I'm definitely open to > patches teaching gdb about them. The example from the original patch for Linux was very useful. I will now try to create a simple (independent of Eclipse) example for Windows. >> If this is supposed to work on Windows already, an example of how to >> do it would be great. I can take that and see where I can get next. >> >> Any thoughts much appreciated. > > The next issue you'll run into is that the new-ui mechanism only > really works if the active target backend supports asynchronous > debugging. The Linux backends supports it. Windows _remote_ debugging > supports it. But Windows _native_ debugging does not (gdb blocks in > windows-nat.c -> WaitForDebugEvent). If you're interested, I can guide you > in the direction of fixing the latter. Just let me know. My primary focus is on embedded developers using Eclipse CDT, so Windows native development is a lower priority for now. Cygwin and MSYS2 are shipping GDB 7.11 so far, so there is no easy path for those users to access the feature yet anyway. ARM's latest release on the other hand is shipping with mingw built GDB 7.12: https://developer.arm.com/open-source/gnu-toolchain/gnu-rm I also have not started looking at how to support Cygwin/MSYS2 GDBs which do have support for PTY's through the emulation layer. Thanks for the help and advice, Jonah