new-ui and Windows

new-ui and Windows

[Jonah Graham]

Hello gdb devs,

I am looking to support the new-ui functionality[1] for Eclipse CDT on
Windows [2]. I have been using it on Linux and have been enjoying it.
Having a full GDB CLI available within Eclipse is a great improvement.

I would like to know if new-ui is supposed to work on Windows with
mingw host? 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.

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.
Thanks,
Jonah


[1] https://sourceware.org/ml/gdb-patches/2016-05/msg00098.html
[2] https://bugs.eclipse.org/516371

~~~
Jonah Graham
Kichwa Coders Ltd.
www.kichwacoders.com

Re: new-ui and Windows

[Eli Zaretskii]

> From: Jonah Graham <jonah@kichwacoders.com>
> Date: Mon, 15 May 2017 13:38:40 +0100
> 
> I would like to know if new-ui is supposed to work on Windows with
> mingw host? 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.

See the discussion which started here:

  https://sourceware.org/ml/gdb-patches/2016-03/msg00414.html

Re: new-ui and Windows

[Pedro Alves]

On 05/15/2017 01:38 PM, Jonah Graham wrote:
> Hello gdb devs,
> 
> I am looking to support the new-ui functionality[1] for Eclipse CDT on
> Windows [2]. I have been using it on Linux and have been enjoying it.
> Having a full GDB CLI available within Eclipse is a great improvement.

Awesome, great to hear.

> 
> I would like to know if new-ui is supposed to work on Windows with
> mingw host?

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.

> 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.

> 
> 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.

Thanks,
Pedro Alves

Re: new-ui and Windows

[Jonah Graham]

On 15 May 2017 at 23:49, Pedro Alves <palves@redhat.com> 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

Re: new-ui and Windows

[Eli Zaretskii]

> From: Jonah Graham <jonah@kichwacoders.com>
> Date: Tue, 16 May 2017 09:45:11 +0100
> Cc: gdb@sourceware.org
> 
> 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

Don't forget this:

  https://sourceforge.net/projects/ezwinports/files/gdb-7.12-w32-bin.zip/download

Re: new-ui and Windows

[Jon Beniston]

>I am looking to support the new-ui functionality[1] for Eclipse CDT on
> Windows [2]. 
> I would like to know if new-ui is supposed to work on Windows with
> mingw host?

I'm just looking at this as well, but for a Cygwin based GDB, rather than
mingw.

>> 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.

I think using serial_open would be quite handy, as presumably this would
allow a TCP connection to Eclipse?

If so, I suspect this would be a lot easier to support in Eclipse, as there
would be no need for JNI code to interface with Cygwin PTYs or Windows named
pipes - and it even could be the same Java code for MacOS and Linux too. 

Do you see any problems with that?

Cheers,
Jon

Re: new-ui and Windows

[Pedro Alves]

On 08/08/2017 03:53 PM, Jon Beniston wrote:

> I think using serial_open would be quite handy, as presumably this would
> allow a TCP connection to Eclipse?
> 
> If so, I suspect this would be a lot easier to support in Eclipse, as there
> would be no need for JNI code to interface with Cygwin PTYs or Windows named
> pipes - and it even could be the same Java code for MacOS and Linux too. 
> 
> Do you see any problems with that?

I'd seem wise to me to avoid that direction, because opening a TCP port
means opening a security hole -- ports are not per-user.

Thanks,
Pedro Alves