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

[Pedro Alves]

On 03/21/2016 05:57 PM, Pedro Alves wrote:
> On 03/21/2016 05:11 PM, Eli Zaretskii wrote:

> 
>>
>>> 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've been thinking a bit on how to make this all work on Windows,
with Eclipse, and my current thinking is that instead of some hack to 
embed a native console window inside the GUI, better would be to reuse 
the same Eclipse terminal emulator widget, and coax gdb
to send the right terminal escape sequences for cursor movement
and character placement as a Unix gdb would.

Instead of a pty, that terminal widget would be backed by a bidirectional
named pipe.  Cygwin ptys use that behind the scenes as well.

So in the end, GDB would be running with input/output connected to a
named pipe, and we'd need to force gdb and ncurses to believe that
that is a terminal.

I'm aware that GNU ncurses, has a concept of "drivers", and it
has a driver for real windows consoles ("win32con") and that is
the default.  AFAIK, the way to select the driver is to set
the TERM env var.

So in theory, all one would need to do is to set the TERM env
var to vt100, xterm, or some such to force the right driver.

The problems will probably be around isatty checks in
readline and ncurses, as you suggested.

There may also be #ifdef WIN32 bits in those libraries that
are #ifdef-ing out code that we'll need, assuming terminal == console,
though I haven't really checked.

The isatty problem looks very much like the problem a native Windows/mingw
program has when run on a Cygwin terminal (and MSYS/MSYS2, which are
Cygwin forks), since Cygwin emulates pseudo terminals via named pipes.
See, e.g.,:

  http://www.spinics.net/lists/git/msg274348.html

So I think it should be possible to make it work on Windows, and I
think it's the right way forward, though some further
ncurses/readline/gdb patching might be in order.

So it looks like if you get native Windows GDB (readline/ncurses)
behaving correctly (history, completion, etc.) when run on a Cygwin
terminal, then from within Eclipse or any other GUI, it would
work as well.

BTW, while investigating this, I found that since some recent
update to Windows 10, Windows consoles now supports ansi/vt100
escape sequences, finally:

 http://www.nivot.org/blog/post/2016/02/04/Windows-10-TH2-%28v1511%29-Console-Host-Enhancements

This further reinforces to me the idea of using ansi escapes on
Windows Eclipse/gdb too.

Thanks,
Pedro Alves