From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 4375 invoked by alias); 12 Oct 2007 17:45:59 -0000 Received: (qmail 4367 invoked by uid 22791); 12 Oct 2007 17:45:59 -0000 X-Spam-Check-By: sourceware.org Received: from rock.gnat.com (HELO rock.gnat.com) (205.232.38.15) by sourceware.org (qpsmtpd/0.31) with ESMTP; Fri, 12 Oct 2007 17:45:57 +0000 Received: from localhost (localhost.localdomain [127.0.0.1]) by filtered-rock.gnat.com (Postfix) with ESMTP id A35042AA7FF; Fri, 12 Oct 2007 13:42:22 -0400 (EDT) Received: from rock.gnat.com ([127.0.0.1]) by localhost (rock.gnat.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id GVkHrPVYw0-d; Fri, 12 Oct 2007 13:42:22 -0400 (EDT) Received: from joel.gnat.com (localhost.localdomain [127.0.0.1]) by rock.gnat.com (Postfix) with ESMTP id 1428A2AAFA0; Fri, 12 Oct 2007 13:42:21 -0400 (EDT) Received: by joel.gnat.com (Postfix, from userid 1000) id 98777E7B58; Fri, 12 Oct 2007 10:42:18 -0700 (PDT) Date: Fri, 12 Oct 2007 17:45:00 -0000 From: Joel Brobecker To: Eli Zaretskii Cc: drow@false.org, Kai.Tietz@onevision.com, gdb@sourceware.org Subject: Re: Support of gdb for Windows 64 native systems Message-ID: <20071012174218.GH4044@adacore.com> References: <20071011142348.GA18239@caradoc.them.org> <20071011145549.GA19918@caradoc.them.org> <20071012161132.GE4044@adacore.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.2i Mailing-List: contact gdb-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sourceware.org X-SW-Source: 2007-10/txt/msg00088.txt.bz2 > So what? the duplicates will never be linked into the same build. We > already have duplicate code in targets that are alike, one more cannot > hurt. I have to disagree on that. We're looking at duplicating 95% of the code. That means duplicating 95% of the maintenance. I just had a look at our code and I was surprised to see how little code is needed now to add support for native win32 support. If it wasn't for copyright issues, I'm thinking that I could be submitting this for inclusion with at most a day or two of work! I'm happy to keep discussing this design aspect, but I think we should leave that discussion to when someone is ready to contribute something. > In my experience, mixing two different targets is asking for trouble > in the long run. It depends. I somehow we could abstract out the code that handles IO in a way that it is transparent to the windows nat code, just the same way we introduced gdb_select, then we can share everything. > > In our merge, I counted 5 instances of "ifdef/ifndef __MINGW32__ > > You need to count "ifdef __CYGWIN__" as well. Actually, currently all except one such ifdef are used as "if on windows". They look like this: #if defined(_WIN32) || defined(__CYGWIN__) The only one is in gdbserver, to convert a solib path into a posix path when using cygwin. > > in total, all of them in win32-nat.c: > > - One to define MAXPATHLEN: Should really be done in a proper way, > > so should go away > > I don't see this one in the current CVS; am I missing something? Yes, this is not necessary on cygwin, and mingw is not supported, so it's only in our (AdaCore) tree (and probably the mingw tree as well). It is: #ifdef __MINGW32__ #define MAXPATHLEN PATH_MAX #endif > > The rest seems to be in i386-win32-tdep.c which is a separate file. > > I don't see this file, either, so I cannot comment on that. Yes, this is normal, because this file is not part of the FSF CVS. It's a separate file that would only be needed for native win32 support. And now that I'm having a closer look at it, it looks like this file is a subset of the cygwin-tdep file, so I should probably experiment with the idea of replacing the win32-tdep file by the cygwin-tdep one! It's been a profitable discussion. Thanks a lot! -- Joel