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: "Pierre Muller" <pierre dot muller at ics-cnrs dot unistra dot fr>
- To: "'Pedro Alves'" <pedro at codesourcery dot com>, <gdb-patches at sourceware dot org>
- Date: Fri, 16 Apr 2010 18:20:18 +0200
- Subject: RE: [RFC] Mingw Windows 64-bit gdbserver
- References: <000d01cadd79$efa9e2b0$cefda810$@muller@ics-cnrs.unistra.fr> <201004161659.37990.pedro@codesourcery.com>
> -----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