Re: Support of gdb for Windows 64 native systems

[Eli Zaretskii <eliz at gnu dot org>]

> Date: Fri, 12 Oct 2007 19:41:16 -0700
> From: Joel Brobecker <brobecker@adacore.com>
> 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 <sys/param.h>
> +#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?