Mailing-List: contact cygwin-help AT sourceware DOT cygnus DOT com; run by ezmlm
Sender: cygwin-owner AT sourceware DOT cygnus DOT com
Delivered-To: mailing list cygwin AT sourceware DOT cygnus DOT com
X-Authentication-Warning: modi.xraylith.wisc.edu: khan owned process doing -bs
Date: Wed, 21 Apr 1999 13:20:03 -0500 (CDT)
From: Mumit Khan <khan AT xraylith DOT wisc DOT edu>
To: Stefano Federici <stefano AT ilc DOT pi DOT cnr DOT it>
cc: cygwin AT sourceware DOT cygnus DOT com
Subject: Re: STDIN redirection under GDB
In-Reply-To: <371DE8D2.7AE94AA2@ilc.pi.cnr.it>
Message-ID: <Pine.SUN.3.93.990421124838.11231A-100000@modi.xraylith.wisc.edu>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII

On Wed, 21 Apr 1999, Stefano Federici wrote:

> I found a similar question in a letter to the list on 1995, but I did
> not find any answer.
> I'm having problems using GDB with a program that uses standard-input.
> I uses gdb 4.17.1 delivered with cygwinb20.1 (I also installed
> egcs.1.1.2, but I don't know if it can influence in any way this
> behaviour).
> All is well when running (other) programs that do not use stdin.  I use
> this form of the run command:
> 
>     run < input
> 
> Where 'input' is my input file, in the current directory.  GDB just sits
> 
> there, forever. I can only break the loop by typing CTRL-C and obtain
> the debugger prompt.
> I also tried to use the argument setting options:
> 
>    set args < input
> 
> but the result is exactly the same.
> 
> Has anyone seen this type of behavior?
> Can it depend on the binary/text mode of cygwin?
> 

It's a bug in all Win32 ports of gdb.

This has to do with how GDB starts a "inferior" subprocess that it
wants to debug; on Unix, it uses the shell to do the redirection, but
on win32, gdb uses CreateProcess. Currently, the cmd arg parser in
win32/gdb doesn't look for redirection symbols, and so it doesn't do
what you'd expect.  Also, someone has to write the small piece of code
that does the redirection by passing the descriptor to CreateProcess
etc.

See target.c (child_create_inferior) for how it's done on Unix boxes and
win32-nat.c (child_create_inferior) for how it's done on win32. 

It can be fixed without too much trouble, but someone needs to do it.

Regards,
Mumit



--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe AT sourceware DOT cygnus DOT com