From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 14998 invoked by alias); 12 Apr 2007 14:56:37 -0000 Received: (qmail 14989 invoked by uid 22791); 12 Apr 2007 14:56:36 -0000 X-Spam-Check-By: sourceware.org Received: from nile.gnat.com (HELO nile.gnat.com) (205.232.38.5) by sourceware.org (qpsmtpd/0.31) with ESMTP; Thu, 12 Apr 2007 15:56:33 +0100 Received: from localhost (localhost [127.0.0.1]) by filtered-nile.gnat.com (Postfix) with ESMTP id EC4EB48CFB3 for ; Thu, 12 Apr 2007 10:56:30 -0400 (EDT) Received: from nile.gnat.com ([127.0.0.1]) by localhost (nile.gnat.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 08492-01-9 for ; Thu, 12 Apr 2007 10:56:30 -0400 (EDT) Received: from joel.gnat.com (dhcp-guest.act-europe.fr [212.157.227.127]) by nile.gnat.com (Postfix) with ESMTP id 9196148CCA3 for ; Thu, 12 Apr 2007 10:56:30 -0400 (EDT) Received: by joel.gnat.com (Postfix, from userid 1000) id 484C5E7B4C; Thu, 12 Apr 2007 16:58:18 +0200 (CEST) Date: Thu, 12 Apr 2007 14:56:00 -0000 From: Joel Brobecker To: gdb@sourceware.org Subject: Re: [mingw32] stdin redirection Message-ID: <20070412145818.GG3886@adacore.com> References: <20070411134219.GA33609@adacore.com> <20070411144451.GA21140@caradoc.them.org> <20070411145104.GE58502@adacore.com> <20070411151234.GA22185@caradoc.them.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20070411151234.GA22185@caradoc.them.org> User-Agent: Mutt/1.4.2.2i Mailing-List: contact gdb-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sourceware.org X-SW-Source: 2007-04/txt/msg00068.txt.bz2 > So fd_is_pipe returns zero either way, but something about calling > PeekNamedPipe on a non-pipe disturbs what happens later, you're saying. Yes, it appears so. > How did it get into WaitForMultipleObjects? Did isatty return true - > in which case it shouldn't have called fd_is_pipe? One piece of information that might be important is the fact that we are running from a cygwin shell. In this case, we no longer have ttys regardless of the way we start GDB (in "terminal" mode, or in non-interactive mode). However, we tried in a DOS window as well, and we had the same result: isatty return false, thus leading us to call fd_is_pipe, followed by the hang up. > Otherwise, see the call site, where no handle is provided. > So we must be falling back to the file handle (mingw-hdep.c). > Maybe we need to do something different to simulate select on a file. Sorry, we're not sure what you mean. Could you elaborate? We've done a bit of debugging on our side, and we now have a better idea of the serial interface in GDB, and probably of why the select layer is implemented the way it is implemented in ser-mingw and mingw-hdep.c. It seems to us that the core of the problem in this case is that PeekNamedPipe does indeed seem to corrupt whatever control structure is associated to our HANDLE. If we could find a way to replace the current implementation of fd_is_pipe into something that avoids using any of the pipe functions, then that would probably solve our problem. Unfortunately, despite our intensive search of MSDN, nothing turned up. However, the little hack we have been using in fd_is_pipe (basically always return false) seems to indicate that it is OK to treat the case of pipes and files the same way. We currently have the following code: is_tty = isatty (scb->fd); if (!is_tty && !fd_is_pipe (scb->fd)) { *read = NULL; *except = NULL; return; } [otherwise, create a bunch of event objects] All the conditions we have tried (interactive-mode in DOS window, interactive mode DOS window but called from cygwin shell, interactive mode from XTERM with cygwin shell, commands sent through pipe in cygwin shell, commands though pipe in DOS window, commands through file in both DOS window and XTERM with cygwin, etc...). So I wonder if it wouldn't just be sufficient to replace the body of fd_is_pipe by a big comment, followed by "return !isatty (fd);". Or, since this function only used there, replace the if condition by if (!is_tty)) Which basically means that we limit the "else" block to the handling of the case when we have a tty. We haven't found any problem with that approach in all the experiments that we have done. Is there something we haven't seen, though? Thanks, -- Joel