From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 14942 invoked by alias); 8 Dec 2006 09:12:52 -0000 Received: (qmail 14922 invoked by uid 22791); 8 Dec 2006 09:12:48 -0000 X-Spam-Check-By: sourceware.org Received: from aquarius.hirmke.de (HELO calimero.vinschen.de) (217.91.18.234) by sourceware.org (qpsmtpd/0.31.1) with ESMTP; Fri, 08 Dec 2006 09:12:44 +0000 Received: by calimero.vinschen.de (Postfix, from userid 500) id B9955544001; Fri, 8 Dec 2006 10:12:41 +0100 (CET) Date: Fri, 08 Dec 2006 09:12:00 -0000 From: Corinna Vinschen To: gdb-patches@sourceware.org Subject: Re: [RFA] win32-nat.c: Simplify generation of Windows environment Message-ID: <20061208091241.GC9829@calimero.vinschen.de> Reply-To: gdb-patches@sourceware.org Mail-Followup-To: gdb-patches@sourceware.org References: <20061207095839.GA14487@calimero.vinschen.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.2i X-IsSubscribed: yes Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org X-SW-Source: 2006-12/txt/msg00114.txt.bz2 On Dec 8 09:31, Eli Zaretskii wrote: > > Cc: gdb-patches@sourceware.org > > From: Jim Blandy > > Date: Thu, 07 Dec 2006 16:10:14 -0800 > > > > $ cd gdb/config > > $ grep -nH -e win32-nat */*.m? > > i386/cygwin.mh:2:NATDEPFILES= i386-nat.o win32-nat.o corelow.o > > $ > > > > I think that means it's just Cygwin. > > No, it just means that the native W32 build is currently not part of > the CVS. How exactly are we supposed to think of and support code which is not part of the source tree when creating a patch? > A large portion of win32-nat.c is relevant to any native Windows > debugger. By contrast, cygwin_internal is obviously Cygwin-specific. > So I think it would be a good practice to mark such specific portions > of code explicitly. As I just wrote in my reply to Jim, the cygwin_internal API is used in GDB for a long time, as a grep will show. If win32-nat.c is used by some not-in-the-source-tree code somewere, it will already have to deal with cygwin_internal. A patch for a native GDB will have created either a matching #define or a substitute for this function anyway. I don't see how this new usage differs from the existing ones. Talking of a native win32 GDB, it shouldn't be bothered at all by my patch. Creating a native Windows environment from Cygwin's environment is not a concern natively. Just setting it to NULL in the call to CreateProcess is sufficient for a native GDB, since that will create a copy of the parent's (GDB's) environment to the child, the same what the longish code does, which I substituted with cygwin_internal(CW_SYN_WINENV). Corinna -- Corinna Vinschen Cygwin Project Co-Leader Red Hat