This is the mail archive of the
mailing list for the GDB project.
Re: Windows support in GDB
- From: "Eli Zaretskii" <eliz at gnu dot org>
- To: gdb at sourceware dot org
- Date: Mon, 02 May 2005 22:00:39 +0300
- Subject: Re: Windows support in GDB
- References: <200504291513.j3TFDhjx021040@elgar.sibelius.xs4all.nl> <20050429153146.GA27362@nevyn.them.org> <20050429160040.GH10017@trixie.casa.cgf.cx> <firstname.lastname@example.org> <20050429163011.GB12864@trixie.casa.cgf.cx> <427267B7.email@example.com> <01c54e87$Blat.firstname.lastname@example.org> <20050501214128.GA23129@trixie.casa.cgf.cx>
- Reply-to: Eli Zaretskii <eliz at gnu dot org>
> Date: Sun, 1 May 2005 17:41:28 -0400
> From: Christopher Faylor <email@example.com>
> >In fact, any serious use of GDB will almost instantly bump into such a
> >consistency (or lack thereof) issue. For example, will the `edit' and
> >`shell' commands work if I don't have a Cygwin Bash installed and GDB
> >is configured to invoke that Bash as the shell?
> And, if they don't, what's the solution? You fix it so they will work.
> Presumably, if there is no /bin/sh.exe available, you'd use a fallback.
> You could even implement a switch to force cygwin's gdb into "windows
> path mode".
You could do all that and more, but AFAIK that'd be against the
``spirit of Cygwin'', which is to solve all incompatibilities in the
runtime, and leave the application sources more or less intact. If
you leave the application sources intact, the Unixy shell assumptions,
like the -c switch and redirection syntax, will be hard to solve
inside the library that implements fork/exec or whatever.
> I *suspect* however, that fixing cygwin's gdb to better handle
> windows paths is probably a lot less work than what Mark did.
I actually think the other way around. But I certainly don't want to
start a Cygwin-yaye-o-nay dispute.