This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
Re: [PATCH] Unbuffer stdout and stderr on windows
- From: Eli Zaretskii <eliz at gnu dot org>
- To: Pedro Alves <palves at redhat dot com>
- Cc: gdb-patches at sourceware dot org, brobecker at adacore dot com, yao at codesourcery dot com
- Date: Fri, 16 Aug 2013 16:42:44 +0300
- Subject: Re: [PATCH] Unbuffer stdout and stderr on windows
- References: <51EE23F8 dot 1070905 at codesourcery dot com> <83wqohw4ee dot fsf at gnu dot org> <20130729192559 dot GA5348 at ednor dot casa dot cgf dot cx> <83d2q1xiyv dot fsf at gnu dot org> <51F6C7B2 dot 3020400 at redhat dot com> <20130731034045 dot GA5565 at ednor dot casa dot cgf dot cx> <20130812211105 dot GA11128 at adacore dot com> <8361v9piop dot fsf at gnu dot org> <20130815173618 dot GA6955 at ednor dot casa dot cgf dot cx> <83eh9uonlg dot fsf at gnu dot org> <20130815175940 dot GD6955 at ednor dot casa dot cgf dot cx> <520E1109 dot 7000304 at redhat dot com> <83y581n5ag dot fsf at gnu dot org> <520E296C dot 8090906 at redhat dot com>
- Reply-to: Eli Zaretskii <eliz at gnu dot org>
> Date: Fri, 16 Aug 2013 14:30:20 +0100
> From: Pedro Alves <palves@redhat.com>
> CC: gdb-patches@sourceware.org, brobecker@adacore.com, yao@codesourcery.com
>
> So how is emacs starting GDB?
Via a pipe, of course. How else could Emacs read what GDB outputs and
interpret it?
> If it is started in a pipe, then what is forcing flushing at line
> ends so that emacs doesn't break?
Emacs has a special machinery to decode EOLs correctly even if input
ends in a CR, and the NL comes later. But this machinery is
heuristics and it's fragile. Right now, the amount of such "broken"
outputs is usually very small, and the fact that GDB flushes its
stdout probably makes it negligibly small. If we cause more of these
instances to happen, the probability of a failure in a given session
will go up.
> IOW, the testsuite is not special, in that if emacs starts
> GDB with io connected to pipes, then it should be having the
> exact same issues the testsuite has.
The test suite is special, AFAIU. The original problem was not with
buffering, it was with mixing stdout and stderr that confused Expect.
An Emacs (human) user will never be confused by any such mix, and I
believe MI output makes the mix improbable.
In any case, I heard no complaints about any such situations, nor did
I ever see that myself.
> We do have "gdb_flush (gdb_stdout)" calls sprinkled through the
> tree. If that is what makes emacs+pipe work, then OK, we can remain
> with stdout fully buffered, but then I'd say that the bug is that
> there are places that miss gdb_flush calls.
Maybe we should dig deeper in the original problem as well, because I
still have only a very vague notion of why would GDB, which is a
single-threaded program, cause mixing when it flushes stdout
regularly. What am I missing?