Re: [RFC] Mingw Windows 64-bit gdbserver

[Pedro Alves <pedro@codesourcery.com>]

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.  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)?
That being possible would be another reason to just merge
the files up from the start.

> 
>  - 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?

> 
>  - 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?

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

-- 
Pedro Alves