Re: [PATCH v2 24/25] Add new command to create extra console/mi UI channels

[Pedro Alves <palves at redhat dot com>]

On 03/21/2016 05:11 PM, Eli Zaretskii wrote:
>> Cc: gdb-patches@sourceware.org
>> From: Pedro Alves <palves@redhat.com>
>> 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