From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 31314 invoked by alias); 13 Oct 2007 17:05:09 -0000 Received: (qmail 31305 invoked by uid 22791); 13 Oct 2007 17:05:09 -0000 X-Spam-Check-By: sourceware.org Received: from pool-71-174-251-188.bstnma.fios.verizon.net (HELO ednor.cgf.cx) (71.174.251.188) by sourceware.org (qpsmtpd/0.31) with ESMTP; Sat, 13 Oct 2007 17:05:06 +0000 Received: by ednor.cgf.cx (Postfix, from userid 201) id DF8762B353; Sat, 13 Oct 2007 13:05:04 -0400 (EDT) Date: Sat, 13 Oct 2007 17:05:00 -0000 From: Christopher Faylor To: gdb@sourceware.org, Joel Brobecker , Kai.Tietz@onevision.com, Eli Zaretskii Subject: Re: Support of gdb for Windows 64 native systems Message-ID: <20071013170504.GA8519@ednor.casa.cgf.cx> Mail-Followup-To: gdb@sourceware.org, Joel Brobecker , Kai.Tietz@onevision.com, Eli Zaretskii 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> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20071013154715.GE29152@adacore.com> User-Agent: Mutt/1.5.16 (2007-06-09) 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/msg00095.txt.bz2 On Sat, Oct 13, 2007 at 08:47:15AM -0700, Joel Brobecker wrote: >> I'm not surprised, in particular because I've seen the patches applied >> by the MinGW folks to produce a native MinGW port. Personally, I >> still think that at this magnitude of ifdef'ing we can certainly >> justify two different targets. > >Yes, it's less clear at this point. Perhaps we can reduce further >the differences. As this thread has shown me, the chopping I have >already done was not nearly enough... > >> But this is not my call, and the prospects of finally having MinGW >> support part of the official repository are so thrilling for me that >> I'd hate if this argument would stand in the way. > >I'm like you, if keeping them separate is what the group decides, >that's also fine with me. Might be more like Chris' call. I'm ok with a limited number of ifdefs since I know that, as you say, it is likely that 95% of the code will be similar. It would be a maintenance nightmare otherwise. >> > +#ifdef _WIN32 >> > + /* The executable must not be closed because it will not been possible to >> > + reopen it later under Windows NT if this executable is the one being >> > + debugged. */ >> > + >> > + if (strstr (name, ".exe") != NULL) >> > + sym_bfd->cacheable = FALSE; >> > + else >> > +#endif >> >> Doesn't Cygwin define _WIN32? If it does, why do you need to >> condition this fragment? > >I wasn't the author of this change, I think it was Jerome Guitton. >Nonetheless, I think that the intent was to try to avoid unexpected >impact on other platforms. The #ifdef can certainly be removed. Cygwin doesn't define _WIN32 but I'm wondering why the above isn't needed for Cygwin, too. If we do go with the ifdef route, it would probably make sense to define a WINDOWSISH or a MINGW_OR_CYGWIN variable. I think there are other parts of the build which do something like that. cgf