[RFC] Mingw Windows 64-bit gdbserver

[Pierre Muller]

> -----Message d'origine-----
> De : gdb-patches-owner@sourceware.org [mailto:gdb-patches-
> owner@sourceware.org] De la part de Pedro Alves
> Envoyé : Friday, April 16, 2010 6:00 PM
> À : gdb-patches@sourceware.org
> Cc : Pierre Muller
> Objet : Re: [RFC] Mingw Windows 64-bit gdbserver
> 
> On Friday 16 April 2010 16:31:51, Pierre Muller wrote:
> >   This patch tries to implement support for
> > gdbserver on Windows 64-bit, using the mingw32
> > cross compiler to windows-64bit.
> >
> >   I am unsure if anyone else already tried this,
> > but searching in gdb-patches I didn't find anything...
> > Don't hesitate to tell me otherwise...
> >
> >   The resulting gdbserver seem usable to me,
> >
> >   I do have a few questions:
> >   - About the new file, win64-amd64-low.c
> > should I remove the copyright years and only leave 2010?
> > should I state that it is adapted from win32-i386-low.c?
> 
> How about instead merging the files, like
> linux-x86-low.c handles both 64-bit and 32-bit?  There's
> a lot of common stuff between both archs support, it
> seems.
 Yes, but ...
>  Also, is there any debug API limitation that would
> make it impossible for a 64-bit gdbserver to debug a 32-bit
> inferior (that is, multi-arch the Windows gdbserver)?
 It not impossible, but it doesn't work 
without using some new API functions:
Wow64GetThreadContext, Wow64GetThreadSelectorEntry,
and Wow64SetThreadContext

See http://msdn.microsoft.com/en-us/library/ms679303%28VS.85%29.aspx

This would also be required to be able to debug win32 
application within a windows 64-bit GDB executable.

Implementing this is probably a larger patch than this one ...

> That being possible would be another reason to just merge
> the files up from the start.

 So that argument falls!
> >
> >  - About gdbserver/configure regeneration:
> > this added several lines:
> > +/* Needed for new procfs interface on sparc-solaris.  */
> > +#define _STRUCTURED_PROC 1
> >   I did use autoconf version 2.64 as required...
> > Is this normal?
> 
> Yes, it just means that someone change src/bfd/bfd.m4,
> and this configure had never been regenerated
> (gdbserver/acinclude.m4 pulls in bfd.m4).
> You could just regenerate the file and apply that bit
> alone, independently of your real gdbserver changes, so
> your changes are clean.  Want to do that?
 Done. 
> >
> >  - About the used communication library:
> >   -lwsock32 was not found by the mingw, but main gdb
> > doesn't seem to use it, should we move to ws2_32 for both win32 and
> win64?
> 
> Don't we need to make gdbserver include windows2.h instead of winsock.h
> too?

 No, I only found #include <windows.h>
> >
> >   I still do have a problem when I connect
> > to win64 gdbserver from a multi target win32 gdb executable,
> > somehow, the library list does not seem to correctly
> > read in the library addresses... Still investigating this.
> > It seems related to the fact that I do not have
> > local copies of my remote DLLs.
> >
> 
> > Final question:
> >   Does that patch deserve a documentation or NEWS entry?
> 
> At least the latter, definitely.
  Should be easy to add.

Pierre