From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 15474 invoked by alias); 13 Oct 2007 10:48:49 -0000 Received: (qmail 15466 invoked by uid 22791); 13 Oct 2007 10:48:48 -0000 X-Spam-Check-By: sourceware.org Received: from nitzan.inter.net.il (HELO nitzan.inter.net.il) (213.8.233.22) by sourceware.org (qpsmtpd/0.31) with ESMTP; Sat, 13 Oct 2007 10:48:46 +0000 Received: from HOME-C4E4A596F7 (IGLD-80-230-42-210.inter.net.il [80.230.42.210]) by nitzan.inter.net.il (MOS 3.7.3a-GA) with ESMTP id IAE10895 (AUTH halo1); Sat, 13 Oct 2007 12:45:59 +0200 (IST) Date: Sat, 13 Oct 2007 10:48:00 -0000 Message-Id: From: Eli Zaretskii To: Joel Brobecker CC: Kai.Tietz@onevision.com, gdb@sourceware.org In-reply-to: <20071013024116.GB29152@adacore.com> (message from Joel Brobecker on Fri, 12 Oct 2007 19:41:16 -0700) Subject: Re: Support of gdb for Windows 64 native systems Reply-to: Eli Zaretskii References: <20071011142348.GA18239@caradoc.them.org> <20071011145549.GA19918@caradoc.them.org> <20071012161132.GE4044@adacore.com> <20071012174218.GH4044@adacore.com> <20071012222842.GD21800@adacore.com> <20071013024116.GB29152@adacore.com> X-IsSubscribed: yes Mailing-List: contact gdb-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sourceware.org X-SW-Source: 2007-10/txt/msg00093.txt.bz2 > Date: Fri, 12 Oct 2007 19:41:16 -0700 > From: Joel Brobecker > Cc: Kai.Tietz@onevision.com, gdb@sourceware.org > > I'm attaching a rough sketch of the changes I think are needed > to adapt the cygwin port to also support mingw. Thanks! > It turns out that there are more changes that I was claiming. I'm not surprised, in particular because I've seen the patches applied by the MinGW folks to produce a native MinGW port. Personally, I still think that at this magnitude of ifdef'ing we can certainly justify two different targets. But this is not my call, and the prospects of finally having MinGW support part of the official repository are so thrilling for me that I'd hate if this argument would stand in the way. IOW, let's have MinGW support in the CVS, and argue about separation later! What follows are some more or less random comments on the patch; HTH. > > > > #ifdef __MINGW32__ > > > > #define MAXPATHLEN PATH_MAX > > > > #endif > > > > > > This, for example, is strictly speaking wrong on Windows: Windows > > > supports much longer file names (up to 32K), if you use Unicode APIs. > > > > You are probably correct, I really know very little about Windows. > > This, I still haven't fixed, because I don't know what the proper > thing to do is. What do you think I should use on Windows? I'll > happily fix it. Well, I don't think you should do anything with the issue of supporting longer file names, because I'm quite sure there are lots of problems with that elsewhere in GDB. I believe GDB currently can only support UTF-8 encoded file names, whereas Windows filesystems use UTF-16. Adding support for Windows non-ASCII file names to GDB will need much more work. However, I'm surprised you needed to define MAXPATHLEN at all, since sys/param.h in the MinGW headers already does that. Can you tell why you need this, and after including sys/param.h on top of that? > #include > +#ifdef __MINGW32__ > + #define MAXPATHLEN PATH_MAX > +#endif What am I missing here? Are you perhaps targeting some old MinGW versions that didn't have that in sys/param.h? > +#ifndef HAVE_CYGWIN_CONV_TO_POSIX_PATH > +/* A basic replacement implementation for cygwin_conv_to_posix_path () > + when not available (basically, when building using a MinGW compiler). */ > + > +static void > +cygwin_conv_to_posix_path (const char *path, char *posix_path) > +{ > + strcpy (posix_path, path); > +} > +#endif > + > +#ifndef HAVE_CYGWIN_CONV_TO_WIN32_PATH > +/* A basic replacement implementation for cygwin_conv_to_win32_path () > + when not available (basically, when building using a MinGW compiler). */ > +static void > +cygwin_conv_to_win32_path (const char *path, char *win32_path) > +{ > + strcpy (win32_path, path); > +} > +#endif I hope these will be eventually rewritten to do something useful, otherwise that's a gratuitous ugliness. > +#ifdef _WIN32 > + /* The executable must not be closed because it will not been possible to > + reopen it later under Windows NT if this executable is the one being > + debugged. */ > + > + if (strstr (name, ".exe") != NULL) > + sym_bfd->cacheable = FALSE; > + else > +#endif Doesn't Cygwin define _WIN32? If it does, why do you need to condition this fragment?