This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
Re: "target remote | " stderr
- From: Mark Kettenis <mark dot kettenis at xs4all dot nl>
- To: ghost at cs dot msu dot su
- Cc: gdb-patches at sources dot redhat dot com
- Date: Sun, 11 Feb 2007 19:09:38 +0100 (CET)
- Subject: Re: "target remote | " stderr
- References: <200701261653.53834.vladimir@codesourcery.com> <20070126140028.GA29456@nevyn.them.org> <epq9dd$k4s$1@sea.gmane.org> <20070131144101.GA23780@nevyn.them.org> <eqnhq8$8nt$1@sea.gmane.org>
> From: Vladimir Prus <ghost@cs.msu.su>
> Date: Sun, 11 Feb 2007 19:55:03 +0300
>
> Daniel Jacobowitz wrote:
>
> > On Wed, Jan 31, 2007 at 05:34:21PM +0300, Vladimir Prus wrote:
> >> Implementing for MinGW required modifying libiberty so that
> >> it can catch stderr to a pipe. Here's a patch for gdb that
> >> relies on the libiberty patch. Does this sound OK
> >> provided libiberty patch is approved?
> >
> > Do we automatically get a non-blocking pipe on mingw, or do we have to
> > set it ourselves?
>
> We have to set it ourself, unfortunately. I had one test case working
> fine, but got gdb hanging on some other.
>
> The attached patch works around the blocking issues, and more extensively
> tested. OK?
Please keep Windows-specific code out of ser-base.c. Is read() on
MinGW fully blocking? Or will it return whatever is available and
only block if nothing is available. Then you could use gdb_select()
to check whether input is available on the pipe.
Otherwise, you should think about introducing an asbtraction layer for
reading from error_fd.
Mark