From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 19275 invoked by alias); 29 Apr 2005 16:57:36 -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 18691 invoked from network); 29 Apr 2005 16:57:25 -0000 Received: from unknown (HELO nimbus.ott.qnx.com) (209.226.137.76) by sourceware.org with SMTP; 29 Apr 2005 16:57:25 -0000 Received: from [10.12.1.181] (dhcpa181.ott.qnx.com [10.12.1.181]) by nimbus.ott.qnx.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id J7M2NM5V; Fri, 29 Apr 2005 12:57:25 -0400 Message-ID: <427267B7.8020107@qnx.com> Date: Fri, 29 Apr 2005 17:00:00 -0000 From: Kris Warkentin User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) MIME-Version: 1.0 To: Christopher Faylor CC: mark@codesourcery.com, paul@codesourcery.com, gdb@sourceware.org Subject: Re: Windows support in GDB 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> In-Reply-To: <20050429163011.GB12864@trixie.casa.cgf.cx> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-SW-Source: 2005-04/txt/msg00231.txt.bz2 Christopher Faylor wrote: >>3) Paths. This is a HUGE problem because you can't assume that your >>Windows customers are interested in using a Unix style of work flow. >>MinGW supports regular Windows paths without the whole /cygdrive/ >>system. If you have a pure Windows app interacting with Cygwin tools >>(take Eclipse for example) you wind up putting an awful lot of cruft in >>to deal with pathname conversion. You can even get problems when your >>debug information in your binary has either Cygwin or Windows paths. >> >> > >Again, AFAIK, gdb works with native paths. If it doesn't then getting >it to work with windows paths seems like a lot less pain that getting >it to be 100% functional in native windows. > Sometimes yes, sometimes no. 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. If the rest of your toolchain is built with MinGW, it makes sense to build everything that way. At the moment, since we're having trouble with gdb on MinGW, we're actually considering what you said, making gdb the exception and just shipping it with a cygwin1.dll until we can get all the kinks ironed out. Another potential gotcha is that it may not work when run under the MinGW environment (as from a bash shell). I haven't checked this for sure but I understand there can be conflicts between msys and cygwin. One other thing I forgot to mention is memory allocation. Cygwin refuses to allocate the maximum memory available so extremely large projects sometimes have trouble, particularily at the link stage. This isn't a problem on MinGW. cheers, Kris