From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <gdb-return-29866-listarch-gdb=sources.redhat.com@sourceware.org>
Received: (qmail 1907 invoked by alias); 12 Oct 2007 16:51:23 -0000
Received: (qmail 1893 invoked by uid 22791); 12 Oct 2007 16:51:22 -0000
X-Spam-Check-By: sourceware.org
Received: from romy.inter.net.il (HELO romy.inter.net.il) (213.8.233.24)     by sourceware.org (qpsmtpd/0.31) with ESMTP; Fri, 12 Oct 2007 16:51:16 +0000
Received: from HOME-C4E4A596F7 ([81.5.57.11]) 	by romy.inter.net.il (MOS 3.7.3-GA) 	with ESMTP id JCE96619 (AUTH halo1); 	Fri, 12 Oct 2007 18:50:55 +0200 (IST)
Date: Fri, 12 Oct 2007 16:51:00 -0000
Message-Id: <uwstsl1j7.fsf@gnu.org>
From: Eli Zaretskii <eliz@gnu.org>
To: Joel Brobecker <brobecker@adacore.com>
CC: drow@false.org, Kai.Tietz@onevision.com, gdb@sourceware.org
In-reply-to: <20071012161132.GE4044@adacore.com> (message from Joel Brobecker 	on Fri, 12 Oct 2007 09:11:32 -0700)
Subject: Re: Support of gdb for Windows 64 native systems
Reply-to: Eli Zaretskii <eliz@gnu.org>
References: <20071011142348.GA18239@caradoc.them.org> <OF95FA8571.7CFDF0D1-ONC1257371.0050CA75-C1257371.005140B3@onevision.de> <20071011145549.GA19918@caradoc.them.org> <u4pgwn2md.fsf@gnu.org> <20071012161132.GE4044@adacore.com>
X-IsSubscribed: yes
Mailing-List: contact gdb-help@sourceware.org; run by ezmlm
Precedence: bulk
List-Id: <gdb.sourceware.org>
List-Subscribe: <mailto:gdb-subscribe@sourceware.org>
List-Archive: <http://sourceware.org/ml/gdb/>
List-Post: <mailto:gdb@sourceware.org>
List-Help: <mailto:gdb-help@sourceware.org>, <http://sourceware.org/ml/#faqs>
Sender: gdb-owner@sourceware.org
X-SW-Source: 2007-10/txt/msg00086.txt.bz2

> Date: Fri, 12 Oct 2007 09:11:32 -0700
> From: Joel Brobecker <brobecker@adacore.com>
> Cc: Daniel Jacobowitz <drow@false.org>, Kai.Tietz@onevision.com,
> 	gdb@sourceware.org
> 
> > Actually, wouldn't it be better to separate the two completely?  That
> > should avoid a lot of ugly ifdefs, and make each native backend much
> > cleaner, I think.
> 
> The issue with that is that we'll end up duplicating a bit of code.

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.

In my experience, mixing two different targets is asking for trouble
in the long run.

> In our merge, I counted 5 instances of "ifdef/ifndef __MINGW32__

You need to count "ifdef __CYGWIN__" as well.

> 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?

> 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.