This is the mail archive of the gdb-patches@sourceware.org mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [PATCH] Unbuffer stdout and stderr on windows


On Mon, Jul 29, 2013 at 08:51:14PM +0100, Pedro Alves wrote:
>On 07/29/2013 08:30 PM, Eli Zaretskii wrote:
>>> Date: Mon, 29 Jul 2013 15:25:59 -0400
>>> From: Christopher Faylor <cgf-use-the-mailinglist-please@sourceware.org>
>>>
>>> Note that this is only a problem for non-Cygwin versions of gdb.  It
>>> sounds like someone is using mingw-built versions of gdb in a cygwin
>>> pty session.
>> 
>> Yes.  Specifically, an attempt to run a MinGW GDB through the test
>> suite using Cygwin expect.
>
>IMO, the ultimate solution is to run the testsuite with a small
>netcat-like wrapper program that creates a console, redirects
>the child's stdin/stdout/stderr to the console, and bridges data
>between the cygwin pipes and the console.
>
> cygwin (io=tty/pipe) <-> [ pipe <-> console ] <-> gdb (io=console)
>
>The testsuite would then spawn "wrapper.exe gdb.exe ..." instead of
>"gdb.exe".
>
>GDB would then see a regular console for stdin/stdout/stderr, and
>work out of the box.  PR15791 points at winpty, an open source
>tool that from the description does that (and more).  It'd be nice
>if that path would be investigated.

We had a somewhat heated debate in the cygwin list about using the
techniques in winpty and eventually abandoned the idea because the way
things like winpty create consoles is not foolproof.  Since it relies on
polling, it is theoretically possible to lose data.

I'll bet that, in practice you'd never see any data loss, though.
And, from that observation, you can see which side of the argument
I was on.  :-)

cgf


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]