From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 18383 invoked by alias); 16 Apr 2010 16:20:32 -0000 Received: (qmail 18265 invoked by uid 22791); 16 Apr 2010 16:20:19 -0000 X-SWARE-Spam-Status: No, hits=-1.8 required=5.0 tests=BAYES_00,MSGID_MULTIPLE_AT,TW_OC X-Spam-Check-By: sourceware.org Received: from mailhost.u-strasbg.fr (HELO mailhost.u-strasbg.fr) (130.79.200.158) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Fri, 16 Apr 2010 16:20:11 +0000 Received: from baal.u-strasbg.fr (baal.u-strasbg.fr [IPv6:2001:660:2402::41]) by mailhost.u-strasbg.fr (8.14.3/jtpda-5.5pre1) with ESMTP id o3GGK4he049969 ; Fri, 16 Apr 2010 18:20:04 +0200 (CEST) (envelope-from pierre.muller@ics-cnrs.unistra.fr) Received: from mailserver.u-strasbg.fr (ms1.u-strasbg.fr [IPv6:2001:660:2402:d::10]) by baal.u-strasbg.fr (8.14.0/jtpda-5.5pre1) with ESMTP id o3GGK4Jb094656 ; Fri, 16 Apr 2010 18:20:04 +0200 (CEST) (envelope-from pierre.muller@ics-cnrs.unistra.fr) Received: from d620muller (gw-ics.u-strasbg.fr [130.79.210.225]) (user=mullerp mech=LOGIN) by mailserver.u-strasbg.fr (8.14.3/jtpda-5.5pre1) with ESMTP id o3GGK3v3064394 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) ; Fri, 16 Apr 2010 18:20:04 +0200 (CEST) (envelope-from pierre.muller@ics-cnrs.unistra.fr) From: "Pierre Muller" To: "'Pedro Alves'" , References: <000d01cadd79$efa9e2b0$cefda810$@muller@ics-cnrs.unistra.fr> <201004161659.37990.pedro@codesourcery.com> In-Reply-To: <201004161659.37990.pedro@codesourcery.com> Subject: RE: [RFC] Mingw Windows 64-bit gdbserver Date: Fri, 16 Apr 2010 16:20:00 -0000 Message-ID: <001901cadd80$b476aff0$1d640fd0$@muller@ics-cnrs.unistra.fr> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org X-SW-Source: 2010-04/txt/msg00513.txt.bz2 > -----Message d'origine----- > De=A0: gdb-patches-owner@sourceware.org [mailto:gdb-patches- > owner@sourceware.org] De la part de Pedro Alves > Envoy=E9=A0: Friday, April 16, 2010 6:00 PM > =C0=A0: gdb-patches@sourceware.org > Cc=A0: Pierre Muller > Objet=A0: Re: [RFC] Mingw Windows 64-bit gdbserver >=20 > 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? >=20 > 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=20 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=20 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? >=20 > 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.=20 > > > > - 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? >=20 > Don't we need to make gdbserver include windows2.h instead of winsock.h > too? No, I only found #include > > > > 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. > > >=20 > > Final question: > > Does that patch deserve a documentation or NEWS entry? >=20 > At least the latter, definitely. Should be easy to add. Pierre