From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 44483 invoked by alias); 21 Mar 2016 17:57:20 -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 44464 invoked by uid 89); 21 Mar 2016 17:57:20 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-0.9 required=5.0 tests=BAYES_00,KAM_LAZY_DOMAIN_SECURITY,RP_MATCHES_RCVD,SPF_HELO_PASS autolearn=no version=3.3.2 spammy=specifying, detach, desktop, online 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; Mon, 21 Mar 2016 17:57:10 +0000 Received: from int-mx14.intmail.prod.int.phx2.redhat.com (int-mx14.intmail.prod.int.phx2.redhat.com [10.5.11.27]) by mx1.redhat.com (Postfix) with ESMTPS id E8AED7F0AC; Mon, 21 Mar 2016 17:57:08 +0000 (UTC) Received: from [127.0.0.1] (ovpn01.gateway.prod.ext.phx2.redhat.com [10.5.9.1]) by int-mx14.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id u2LHv7fx020286; Mon, 21 Mar 2016 13:57:08 -0400 Subject: Re: [PATCH v2 24/25] Add new command to create extra console/mi UI channels To: Eli Zaretskii References: <1458573675-15478-1-git-send-email-palves@redhat.com> <1458573675-15478-25-git-send-email-palves@redhat.com> <83twjz6bex.fsf@gnu.org> <56F02689.2050503@redhat.com> <83r3f369io.fsf@gnu.org> Cc: gdb-patches@sourceware.org From: Pedro Alves Message-ID: <56F035F3.6060702@redhat.com> Date: Mon, 21 Mar 2016 17:57:00 -0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.6.0 MIME-Version: 1.0 In-Reply-To: <83r3f369io.fsf@gnu.org> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-SW-Source: 2016-03/txt/msg00421.txt.bz2 On 03/21/2016 05:11 PM, Eli Zaretskii wrote: >> Cc: gdb-patches@sourceware.org >> From: Pedro Alves >> Date: Mon, 21 Mar 2016 16:51:21 +0000 >> >>> Shouldn't this (and other related) code be conditional of PTYs being >>> supported? Otherwise, this is just useless baggage, right? >> >> Actually this should all work on Windows too, for example. > > Are you sure? The code does this, for example: > >> +static FILE * >> +open_stream (const char *name) >> +{ >> + int fd; >> + >> + fd = open (name, O_RDWR | O_NOCTTY); >> + if (fd < 0) >> + perror_with_name (_("opening terminal failed")); >> + >> + return fdopen (fd, "w+"); >> +} > > How do you expect this to work on Windows? For starters, O_NOCTTY is > not supported. I thought I had tried building this on Windows, looks like not. I was misled by this bit in windows-nat.c: tty = open (inferior_io_terminal, O_RDWR | O_NOCTTY); but I see now that that's Cygwin only. inflow.c has this at the top: #ifndef O_NOCTTY #define O_NOCTTY 0 #endif guess I'll do the same here. > And what would you use for 'name' here? More > importantly, each Windows process can have only one console at a time, > AFAIK. > > Am I missing something? Hmm, I thought you could create multiple Windows consoles in a process, but I now see you can't unless you detach from the previous console: https://msdn.microsoft.com/en-us/library/windows/desktop/ms682528%28v=vs.85%29.aspx I imagine it should be possible to start GDB in MI mode, with no console attached, and then do "new-ui console con1:" and have gdb attach to that console. Since there'd be only one CLI instance inside gdb when run like this, we could support line editing / readline on this secondary UI, though we don't, not yet. That would require more work, on GNU/Linux too. FAOD, it does work to start gdb in MI and create a secondary CLI UI, but it'll not have readline active (it works as if you started gdb with isatty(0)==0, or with "set editing off"). But the way I see it working is that the frontend creates a bidirectional named pipe, with CreateNamedPipe(PIPE_ACCESS_DUPLEX), for MI communication. Then it starts GDB in console mode, attached to a real console window embedded in the frontend's GUI (*) and tells gdb to open the MI ui on the named pipe. Like: $ gdb -q -ex "new-ui mi \\.\pipe\pipename" I _think_ that should work, but it's been years since I did anything closely related on Windows. * - years ago when I had to use Windows on a regular basis, I used the Console2 program, which has multiple console windows, though I don't know exact details of how. Maybe some multi-process trick. > >> MI doesn't really need a PTY, so even though currently the command's >> online help and git logs say usage is "new-ui INTERP TTY", that TTY part >> could actually be the name of any bidirectional stream. >> >> E.g., it could be a bidi unix domain socket, on Linux, or on Windows, >> I think it should work to pass a console name, or a bidirectional >> named pipe path, though I haven't tried it. > > There are no Unix domain sockets on Windows, AFAIK. As for a console > name, see above. There are bidirectional named pipes though. > >> If necessary, it would also be easy to extend the command to support >> separate streams for in/out/err, like, e.g.: >> >> (gdb) new-ui INTERP IN OUT ERR >> >> And then it'd be possible to open a new MI channel through >> unidirectional named pipes, regular files, etc. too. > > But doesn't readline need a console-compatible device? PTYs pass the > isatty test, but pipes and regular files fail it, so will readline at > all work? You'll normally be specifying "MI" as INTERP, which does not need to use readline at all. So as mentioned above, a frontend first starts GDB in console mode, with stdin/stdout/stderr associated with a PTY/console, and then opens a secondary ui with "new-ui" for MI. And this MI ui does _not_ need to pass the isatty test, as MI does not really need a terminal for anything. > I have a dreadful feeling that I'm missing something very important > here, because I'm sure I don't tell anything you don't already know. Thanks, Pedro Alves