Mirror of the gdb mailing list
 help / color / mirror / Atom feed
From: Pedro Alves <palves@redhat.com>
To: Jonah Graham <jonah@kichwacoders.com>, gdb@sourceware.org
Subject: Re: new-ui and Windows
Date: Mon, 15 May 2017 22:49:00 -0000	[thread overview]
Message-ID: <4c77fe53-dafc-3376-6f00-21e69289e39e@redhat.com> (raw)
In-Reply-To: <CAPmGMvivbG706SborUxcYLZ+Zt+0hhS_vdfCDe4PYey0w6zUVg@mail.gmail.com>

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


  parent reply	other threads:[~2017-05-15 22:49 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-05-15 12:39 Jonah Graham
2017-05-15 19:18 ` Eli Zaretskii
2017-05-15 22:49 ` Pedro Alves [this message]
2017-05-16  8:52   ` Jonah Graham
2017-05-16 18:34     ` Eli Zaretskii
2017-08-08 14:53 Jon Beniston
2017-08-08 15:09 ` Pedro Alves

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4c77fe53-dafc-3376-6f00-21e69289e39e@redhat.com \
    --to=palves@redhat.com \
    --cc=gdb@sourceware.org \
    --cc=jonah@kichwacoders.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox