From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 14735 invoked by alias); 17 Apr 2010 05:40:08 -0000 Received: (qmail 14455 invoked by uid 22791); 17 Apr 2010 05:40:06 -0000 X-SWARE-Spam-Status: No, hits=-1.9 required=5.0 tests=BAYES_00,MSGID_MULTIPLE_AT X-Spam-Check-By: sourceware.org Received: from mailhost.u-strasbg.fr (HELO mailhost.u-strasbg.fr) (130.79.200.151) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Sat, 17 Apr 2010 05:40:01 +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 o3H5dss4003919 ; Sat, 17 Apr 2010 07:39:54 +0200 (CEST) (envelope-from pierre.muller@ics-cnrs.unistra.fr) Received: from mailserver.u-strasbg.fr (ms2.u-strasbg.fr [IPv6:2001:660:2402:d::11]) by baal.u-strasbg.fr (8.14.0/jtpda-5.5pre1) with ESMTP id o3H5drLb068776 ; Sat, 17 Apr 2010 07:39:53 +0200 (CEST) (envelope-from pierre.muller@ics-cnrs.unistra.fr) Received: from d620muller (lec67-4-82-230-53-140.fbx.proxad.net [82.230.53.140]) (user=mullerp mech=LOGIN) by mailserver.u-strasbg.fr (8.14.3/jtpda-5.5pre1) with ESMTP id o3H5dqs0055342 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) ; Sat, 17 Apr 2010 07:39:53 +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: Sat, 17 Apr 2010 05:40:00 -0000 Message-ID: <001f01caddf0$6d4246b0$47c6d410$@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/msg00525.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.=20 Of course, I agree with you that the two files share a very large common portion that is identical. There are only two places where they really differ: For the call to the init_registers_XXX and for the register mappings array. The main question is how should we split these parts=20 off if we want to keep a common part: I would propose this: rename win32-i386-low.c to win-x86-low.c Create win32-i386-low.h and win64-amd64-low.h that would have the register mappings and a macro to define their local init_registers. The problem with this approach is that I=20 don't know if it is OK to put a static array (the mappings) into a header? If this is not regarded as a good C practice we could use win32-i386-low.c and win64-amd64-low.c to directly include the same things as the headers I described above and include the C files instead. I was thinking that including C files directly was not good practice, but it is already used for the=20 files generated from the XML feature files, so=20 this might be a second option. Please just let me know which option seems more favorable to you and I will try to=20 implement it. Pierre