Re: Windows support in GDB

[Kris Warkentin <kewarken@qnx.com>]

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