Re: Support of gdb for Windows 64 native systems

[Joel Brobecker <brobecker at adacore dot com>]

Hello Eli,

I was able to get rid of i386-win32-tdep.c and use i386-cygwin-tdep.c
instead. So one more difference gone. I fixed the problem with
including <sys/procfs.h> trivially, since we already check for
this include file during the configure phase. The size of the
patch has reduced quite a bit thanks to our discussing this together.

I'm attaching a rough sketch of the changes I think are needed
to adapt the cygwin port to also support mingw. It turns out
that there are more changes that I was claiming. My approach
of serching for ifdefs was a bit over simplistic. Since we have
copyright assignment issues anyway, I haven't tried to be extremely
precise in the patch, as I can't officially submit it for inclusion.
However, this gives a rough idea of the magnitude of the task.

Please ignore the TO_HOST_DIR_SPEC etc changes. These are relics
from the times when we used to provide a cygwin debugger that
pretended to be mingw debugger by outputing/accepting mingw paths.
We should really clean these out of our tree someday...

Back when I worked on this, my approach was to patch only the
files that I thought needed to be patched, rather than importing
the entire mega patch. However, I did tend to apply blindly
the pieces I took, so I don't necessarily know that all the
changes in win32-nat.c are necessary. That's a cleanup left
for later.

I haven't included the configure.tgt change, since it is trivial.
I might be missing some configure.ac changes, I'm not sure.

Here is the mingw.mt makefile fragment:

    # Target: Intel x86 running Win32 (MinGW)
    TDEPFILES= i386-tdep.o i386-cygwin-tdep.o i387-tdep.o solib-target.o
    DEPRECATED_TM_FILE= tm-mingw32.h
    GDBSERVER_DEPFILES=

Unfortunately, as you can see, we're still using a tm file, which
only contains the following definition:

    #define ATTACH_NO_WAIT

It should be pretty easy to work around this. It's strange that
mingw would require it and not cygwin, but I haven't looked deaper
into this. Perhaps cygwin does some magic to fake an event.
It just happens that I had to do the same in my wait loop on
my WTX backend (for VxWorks).

> > >     #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.

-- 
Joel

Attachment: mingw.diff
Description: Text document