From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 5058 invoked by alias); 13 Oct 2007 15:47:27 -0000 Received: (qmail 5050 invoked by uid 22791); 13 Oct 2007 15:47:26 -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; Sat, 13 Oct 2007 15:47:20 +0000 Received: from localhost (localhost.localdomain [127.0.0.1]) by filtered-rock.gnat.com (Postfix) with ESMTP id 6B2661E6F3B; Sat, 13 Oct 2007 11:47:18 -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 yuNOFeZNwrg8; Sat, 13 Oct 2007 11:47:18 -0400 (EDT) Received: from joel.gnat.com (localhost.localdomain [127.0.0.1]) by rock.gnat.com (Postfix) with ESMTP id 0C2411E6E07; Sat, 13 Oct 2007 11:47:18 -0400 (EDT) Received: by joel.gnat.com (Postfix, from userid 1000) id C43C7E7B58; Sat, 13 Oct 2007 08:47:15 -0700 (PDT) Date: Sat, 13 Oct 2007 15:47:00 -0000 From: Joel Brobecker To: Eli Zaretskii Cc: Kai.Tietz@onevision.com, gdb@sourceware.org Subject: Re: Support of gdb for Windows 64 native systems Message-ID: <20071013154715.GE29152@adacore.com> References: <20071011145549.GA19918@caradoc.them.org> <20071012161132.GE4044@adacore.com> <20071012174218.GH4044@adacore.com> <20071012222842.GD21800@adacore.com> <20071013024116.GB29152@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/msg00094.txt.bz2 > 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. Note however, it's not a done deal yet, because the patches are slightly tainted by copyright assignment issues. Some of the changes have been replaced by my work, so you can say they are AdaCore's, but some others have been imported straight from the MinGW patch. Let's try to reduce it as much as we can, and then I'll try to track down all the authors of the pieces that are left. > > #include > > +#ifdef __MINGW32__ > > + #define MAXPATHLEN PATH_MAX > > +#endif > > What am I missing here? Are you perhaps targeting some old MinGW > versions that didn't have that in sys/param.h? You're right - it turns out this one is not needed anymore. > > +#ifndef HAVE_CYGWIN_CONV_TO_WIN32_PATH > > +/* A basic replacement implementation for cygwin_conv_to_win32_path () > > + when not available (basically, when building using a MinGW compiler). */ > > +static void > > +cygwin_conv_to_win32_path (const char *path, char *win32_path) > > +{ > > + strcpy (win32_path, path); > > +} > > +#endif > > I hope these will be eventually rewritten to do something useful, > otherwise that's a gratuitous ugliness. The thing is that they don't need to do anything useful. The PATH is already in win32 format. > > +#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. In fact, this change is not necessary at all, it's just a convenience in the following scenario (IIRC): After having debugged your exe, you found the bug, so you use the "kill" command to kill the process and, while leaving the debugger up and running, try to rebuild your program. Because GDB still has a handle on the EXE, the windows filesystem doesn't let you delete the file to replace with the new one. So this can be handled as a separate patch. I think at this point that the next thing to do is to review carefully the patch, and evaluate what is needed and what isn't anymore. Then we can tackle the issue of copyright assignement, and then finally submit/discuss a new patch. -- Joel