From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 22189 invoked by alias); 16 Apr 2010 15:59:49 -0000 Received: (qmail 22173 invoked by uid 22791); 16 Apr 2010 15:59:47 -0000 X-SWARE-Spam-Status: No, hits=-1.8 required=5.0 tests=BAYES_00,TW_OC,T_RP_MATCHES_RCVD X-Spam-Check-By: sourceware.org Received: from mail.codesourcery.com (HELO mail.codesourcery.com) (38.113.113.100) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Fri, 16 Apr 2010 15:59:42 +0000 Received: (qmail 25209 invoked from network); 16 Apr 2010 15:59:40 -0000 Received: from unknown (HELO orlando.localnet) (pedro@127.0.0.2) by mail.codesourcery.com with ESMTPA; 16 Apr 2010 15:59:40 -0000 From: Pedro Alves To: gdb-patches@sourceware.org Subject: Re: [RFC] Mingw Windows 64-bit gdbserver Date: Fri, 16 Apr 2010 15:59:00 -0000 User-Agent: KMail/1.12.2 (Linux/2.6.31-20-generic; KDE/4.3.2; x86_64; ; ) Cc: "Pierre Muller" References: <000d01cadd79$efa9e2b0$cefda810$@muller@ics-cnrs.unistra.fr> In-Reply-To: <000d01cadd79$efa9e2b0$cefda810$@muller@ics-cnrs.unistra.fr> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201004161659.37990.pedro@codesourcery.com> X-IsSubscribed: yes 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/msg00509.txt.bz2 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