From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 25374 invoked by alias); 1 May 2005 21:41:33 -0000 Mailing-List: contact gdb-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sources.redhat.com Received: (qmail 25360 invoked from network); 1 May 2005 21:41:28 -0000 Received: from unknown (HELO cgf.cx) (66.30.17.189) by sourceware.org with SMTP; 1 May 2005 21:41:28 -0000 Received: by cgf.cx (Postfix, from userid 201) id 4056213C373; Sun, 1 May 2005 17:41:28 -0400 (EDT) Date: Sun, 01 May 2005 21:41:00 -0000 From: Christopher Faylor To: mark@codesourcery.com, paul@codesourcery.com, gdb@sourceware.org Subject: Re: Windows support in GDB Message-ID: <20050501214128.GA23129@trixie.casa.cgf.cx> Mail-Followup-To: mark@codesourcery.com, paul@codesourcery.com, gdb@sourceware.org References: <200504291513.j3TFDhjx021040@elgar.sibelius.xs4all.nl> <20050429153146.GA27362@nevyn.them.org> <20050429160040.GH10017@trixie.casa.cgf.cx> <42726061.5090101@qnx.com> <20050429163011.GB12864@trixie.casa.cgf.cx> <427267B7.8020107@qnx.com> <01c54e87$Blat.v2.4$40320aa0@zahav.net.il> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <01c54e87$Blat.v2.4$40320aa0@zahav.net.il> User-Agent: Mutt/1.5.8i X-SW-Source: 2005-05/txt/msg00009.txt.bz2 On Sun, May 01, 2005 at 10:51:02PM +0300, Eli Zaretskii wrote: >> Date: Fri, 29 Apr 2005 12:58:31 -0400 >> From: Kris Warkentin >> CC: mark@codesourcery.com, paul@codesourcery.com, gdb@sourceware.org >> >> It isn't just an issue of gdb not working with native paths because, >> as you say, it _usually_ does. It's a question of consistency. > >Indeed. > >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". Problems like "what happens when there is no cygwin shell available?" are fixable. They are likely to be fixable without the necessity of sprinkling ifdefs all over gdb or even making changes to the configury. I don't think that they can be used as a justification for a windows port. No matter how you slice it, changes to get gdb working on native windows are at least mildly intrusive. Maybe compatibility changes to make a cygwin-based gdb work better would be equally intrusive or time consuming. I *suspect* however, that fixing cygwin's gdb to better handle windows paths is probably a lot less work than what Mark did. I think I can say with some assurance that there would be no need to modify readline at all, for instance. So, I don't think that any observations about the way that gdb currently works under cygwin should be considered fodder for why a native windows port is required. Mark expended some effort to produce a native windows port rather than fix any problems that cropped up with cygwin gdb. That's fine and dandy. He gave his valid reasons for doing this and it is solely his perogative. I don't think we need to search for (fixable) limitations in cygwin's gdb as a rationale for why a windows port is needed. cgf