Re: Support of gdb for Windows 64 native systems

[Joel Brobecker <brobecker@adacore.com>]

> > I have to disagree on that. We're looking at duplicating 95% of
> > the code. That means duplicating 95% of the maintenance.
> 
> I assumed the two files will have different maintainers, too.

I would like us to avoid this situation if we can because
we'll waste time keeping the two ports in sync. I'm actually
ready to accept a situation where Chris doesn't have to worry
at all about breaking MingW, and I'll fix the broken pieces as
I discover them.

> > Actually, currently all except one such ifdef are used as "if on
> > windows". They look like this:
> > 
> >    #if defined(_WIN32) || defined(__CYGWIN__)
> 
> Not in the GDB CVS.

Sorry, you're right. But I think my point still stands: Most __CYGWIN__
ifdefs are here to mean "if we are on windows", and the same code
would apply for both ports.

> >     #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.
My point was that this is the wrong way of doing it anyway, so this
too will go, thus reducing a bit more the differences.

> > > > 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.
> 
> Well, in that case, maybe you already refactored the code in a way
> that makes my points moot.

I did chop a lot of code off, that's for sure :). That was thanks
to CodeSourcery's work in porting GDB to MinGW as a host. I have
created some action items on my side to investigate how much
I can get rid of... So far today, I'm working on getting my latest
merge to work, and then I'll take a look at this.

-- 
Joel