This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
Re: [RFC] Mingw Windows 64-bit gdbserver
- From: Pedro Alves <pedro at codesourcery dot com>
- To: gdb-patches at sourceware dot org
- Cc: "Pierre Muller" <pierre dot muller at ics-cnrs dot unistra dot fr>
- Date: Fri, 16 Apr 2010 16:59:37 +0100
- Subject: Re: [RFC] Mingw Windows 64-bit gdbserver
- References: <000d01cadd79$efa9e2b0$cefda810$@muller@ics-cnrs.unistra.fr>
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