This is the mail archive of the
gdb@sourceware.org
mailing list for the GDB project.
Re: Support of gdb for Windows 64 native systems
> 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