From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 23767 invoked by alias); 12 Oct 2007 22:28:56 -0000 Received: (qmail 23758 invoked by uid 22791); 12 Oct 2007 22:28:56 -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 22:28:54 +0000 Received: from localhost (localhost.localdomain [127.0.0.1]) by filtered-rock.gnat.com (Postfix) with ESMTP id A5C081E687F; Fri, 12 Oct 2007 18:28:45 -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 0Gb5tZUqJB9Y; Fri, 12 Oct 2007 18:28:45 -0400 (EDT) Received: from joel.gnat.com (localhost.localdomain [127.0.0.1]) by rock.gnat.com (Postfix) with ESMTP id 4B8FF1E6748; Fri, 12 Oct 2007 18:28:45 -0400 (EDT) Received: by joel.gnat.com (Postfix, from userid 1000) id CF347E7B58; Fri, 12 Oct 2007 15:28:42 -0700 (PDT) Date: Fri, 12 Oct 2007 22:28: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: <20071012222842.GD21800@adacore.com> References: <20071011142348.GA18239@caradoc.them.org> <20071011145549.GA19918@caradoc.them.org> <20071012161132.GE4044@adacore.com> <20071012174218.GH4044@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/msg00090.txt.bz2 > > I have to disagree on that. We're looking at duplicating 95% of > > the code. That means duplicating 95% of the maintenance. > > I assumed the two files will have different maintainers, too. I would like us to avoid this situation if we can because we'll waste time keeping the two ports in sync. I'm actually ready to accept a situation where Chris doesn't have to worry at all about breaking MingW, and I'll fix the broken pieces as I discover them. > > Actually, currently all except one such ifdef are used as "if on > > windows". They look like this: > > > > #if defined(_WIN32) || defined(__CYGWIN__) > > Not in the GDB CVS. Sorry, you're right. But I think my point still stands: Most __CYGWIN__ ifdefs are here to mean "if we are on windows", and the same code would apply for both ports. > > #ifdef __MINGW32__ > > #define MAXPATHLEN PATH_MAX > > #endif > > This, for example, is strictly speaking wrong on Windows: Windows > supports much longer file names (up to 32K), if you use Unicode APIs. You are probably correct, I really know very little about Windows. My point was that this is the wrong way of doing it anyway, so this too will go, thus reducing a bit more the differences. > > > > 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. > > Well, in that case, maybe you already refactored the code in a way > that makes my points moot. I did chop a lot of code off, that's for sure :). That was thanks to CodeSourcery's work in porting GDB to MinGW as a host. I have created some action items on my side to investigate how much I can get rid of... So far today, I'm working on getting my latest merge to work, and then I'll take a look at this. -- Joel