Re: Support of gdb for Windows 64 native systems

[Joel Brobecker <brobecker@adacore.com>]

> So what? the duplicates will never be linked into the same build.  We
> already have duplicate code in targets that are alike, one more cannot
> hurt.

I have to disagree on that. We're looking at duplicating 95% of
the code. That means duplicating 95% of the maintenance. I just
had a look at our code and I was surprised to see how little code
is needed now to add support for native win32 support. If it wasn't
for copyright issues, I'm thinking that I could be submitting this
for inclusion with at most a day or two of work!

I'm happy to keep discussing this design aspect, but I think we should
leave that discussion to when someone is ready to contribute something.

> In my experience, mixing two different targets is asking for trouble
> in the long run.

It depends. I somehow we could abstract out the code that handles
IO in a way that it is transparent to the windows nat code, just
the same way we introduced gdb_select, then we can share everything.

> > In our merge, I counted 5 instances of "ifdef/ifndef __MINGW32__
> 
> You need to count "ifdef __CYGWIN__" as well.

Actually, currently all except one such ifdef are used as "if on
windows". They look like this:

   #if defined(_WIN32) || defined(__CYGWIN__)

The only one is in gdbserver, to convert a solib path into a
posix path when using cygwin.

> > in total, all of them in win32-nat.c:
> >   - One to define MAXPATHLEN: Should really be done in a proper way,
> >     so should go away
> 
> I don't see this one in the current CVS; am I missing something?

Yes, this is not necessary on cygwin, and mingw is not supported,
so it's only in our (AdaCore) tree (and probably the mingw tree as
well). It is:

    #ifdef __MINGW32__
      #define MAXPATHLEN PATH_MAX
    #endif

> > The rest seems to be in i386-win32-tdep.c which is a separate file.
> 
> I don't see this file, either, so I cannot comment on that.

Yes, this is normal, because this file is not part of the FSF CVS.
It's a separate file that would only be needed for native win32 support.
And now that I'm having a closer look at it, it looks like this file
is a subset of the cygwin-tdep file, so I should probably experiment
with the idea of replacing the win32-tdep file by the cygwin-tdep one!

It's been a profitable discussion. Thanks a lot!

-- 
Joel