This is the mail archive of the
gdb@sources.redhat.com
mailing list for the GDB project.
Re: gdb run < file
- To: cygwin at cygwin dot com, gdb at sources dot redhat dot com
- Subject: Re: gdb run < file
- From: "Eli Zaretskii" <eliz at is dot elta dot co dot il>
- Date: Fri, 29 Jun 2001 10:11:54 +0300
- CC: Takaaki dot Ota at am dot sony dot com, cygwin at cygwin dot com, gdb at sources dot redhat dot com, jimb at redhat dot com
- References: <20010626.234402.21347360.Takaaki.Ota@am.sony.com> <20010627025036.B20160@redhat.com> <20010627.235700.01365880.Takaaki.Ota@am.sony.com> <20010628220602.A3596@redhat.com>
- Reply-to: Eli Zaretskii <eliz at is dot elta dot co dot il>
> Date: Thu, 28 Jun 2001 22:06:02 -0400
> From: Christopher Faylor <cgf@redhat.com>
>
> I'm sorry but I don't think that this is the correct way to deal with
> this. I think that gdb normally handles things like redirection and
> globbing by starting inferior processes via the user's shell. Then it
> uses some kind of "follow fork" method to notice when the process is
> finally started.
I don't know anything about Windows debugging interface, but it might
be that putting a shell between the debugger and the debuggee breaks
something.
Going through the shell also has the limitation that you buy whatever
idiosyncrasies there are in that shell. Unlike on Unix, where the
redirection behavior is quite similar between the shells, on Windows
there's a very wide disagreement. (We are fed up with that nuisance
in the Emacs-land.) So I think there's a lot of sense in having a
unified, predictable redirection support inside GDB that doesn't
depend on the queer shell the user happens to have.
FWIW, the DJGPP port of GDB does something very similar to the patch
we discuss here (except that it also has to flip redirections every
time the execution thread jumps from the debugger to the debuggee).
See go32-nat.c (the actual implementation of the redirection routines
is in the DJGPP debug support library).