From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 28894 invoked by alias); 13 Oct 2007 19:19:39 -0000 Received: (qmail 28886 invoked by uid 22791); 13 Oct 2007 19:19:38 -0000 X-Spam-Check-By: sourceware.org Received: from ug-out-1314.google.com (HELO ug-out-1314.google.com) (66.249.92.171) by sourceware.org (qpsmtpd/0.31) with ESMTP; Sat, 13 Oct 2007 19:19:31 +0000 Received: by ug-out-1314.google.com with SMTP id o2so829763uge for ; Sat, 13 Oct 2007 12:19:28 -0700 (PDT) Received: by 10.66.221.6 with SMTP id t6mr5853771ugg.1192303167797; Sat, 13 Oct 2007 12:19:27 -0700 (PDT) Received: from ?88.210.73.151? ( [88.210.73.151]) by mx.google.com with ESMTPS id i8sm2906021nfh.2007.10.13.12.19.25 (version=TLSv1/SSLv3 cipher=RC4-MD5); Sat, 13 Oct 2007 12:19:26 -0700 (PDT) Message-ID: <47111A25.2020402@portugalmail.pt> Date: Sat, 13 Oct 2007 19:19:00 -0000 From: Pedro Alves User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; pt-BR; rv:1.8.1.6) Gecko/20070728 Thunderbird/2.0.0.6 Mnenhy/0.7.5.0 MIME-Version: 1.0 To: Eli Zaretskii CC: brobecker@adacore.com, Kai.Tietz@onevision.com, gdb@sourceware.org Subject: Re: Support of gdb for Windows 64 native systems References: <20071011145549.GA19918@caradoc.them.org> <20071012161132.GE4044@adacore.com> <20071012174218.GH4044@adacore.com> <20071012222842.GD21800@adacore.com> <20071013024116.GB29152@adacore.com> <20071013154715.GE29152@adacore.com> <4711021C.8010805@portugalmail.pt> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-IsSubscribed: yes 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/msg00098.txt.bz2 Eli Zaretskii wrote: >> I propose goind the other way around. Start by adding the needed configury >> bits needed, a mingw.mt file, and disabling the cygwin specific bits in >> win32-nat.c around #ifdef __CYGWIN__ blocks. I'd like to keep the >> changes mostly in sync with gdbserver/win32-low.c too, but that shouldn't >> be a priority. We can then peacewise enhance the mingw port and bring >> its features up. > > We don't need to go that slow. > Sure, but it's the natural way to introduce the new target. I'm not saying it should be done slowly timewise. I'm saying it should start from the bottom up patchwise. It can be submitted in a patch series in the same minute for all I care. The point is, we shouldn't be looking at a patch and deciding what we *don't* need; we should be looking at what we have, and deciding what we *do* need. -- Cheers, Pedro Alves