From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 13233 invoked by alias); 8 Dec 2006 08:57:31 -0000 Received: (qmail 13221 invoked by uid 22791); 8 Dec 2006 08:57:29 -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 08:57:22 +0000 Received: by calimero.vinschen.de (Postfix, from userid 500) id A8BEB544001; Fri, 8 Dec 2006 09:57:19 +0100 (CET) Date: Fri, 08 Dec 2006 08:57:00 -0000 From: Corinna Vinschen To: gdb-patches@sourceware.org Subject: Re: [RFA] win32-nat.c: Simplify generation of Windows environment Message-ID: <20061208085719.GB9829@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/msg00113.txt.bz2 On Dec 7 11:49, Jim Blandy wrote: > Corinna Vinschen writes: > > the below patch simplifies the code which translates the Cygwin > > environment into the native Windows environment. So far this is > > done in GDB manually. However, there's a Cygwin specific function > > call which does the same for the calling process. Using this call > > has three advantages. > > > > - We can drop a rather big chunk of code from GDB which should be the > > task of Cygwin anyway. > > - By using the Cygwin method of converting the environment, we take > > care of all environment variables which have to be converted in > > some way; not only the PATH variable, but all variables which are > > also translated by Cygwin, thus making this process more transparent. > > - Subsequent changes in Cygwin don't require to change GDB. > > > > > > Ok to apply? > > I'm very much inclined to take your advice on Cygwin-related issues, > and I love the deletion of code, but I still have some questions: > > Is it really okay to call cygwin_internal? (That's not the name I'd > expect a public, stable interface to have.) cygwin_internal is a stable interface existing for a lot of years. It's supposed to provide an interface to Cygwin internal functionality which is not covered by any "official" POSIX/Linux/BSD API. Functionality is never removed from this function. It's used already for quite some time in gdb: $ grep -n cygwin_internal win32-nat.c 1738: pid = cygwin_internal (CW_CYGWIN_PID_TO_WINPID, pid); 1813: cygwin_internal (CW_LOCK_PINFO, 1000); 1816: cygwin_internal (CW_GETPINFO, cpid | CW_NEXTPID)); 1826: cygwin_internal (CW_UNLOCK_PINFO); > How well will this work on older versions of Cygwin? Will people > still be able to compile GDB against the Cygwin versions they can now? The interface exists since at least 1999, but CW_SYNC_WINENV has been introduced in February 2006. This requires at least Cygwin 1.5.21, which is the version before the current version. I didn't expect that we're trying to support old Cygwin versions in new GDB versions, though. Corinna -- Corinna Vinschen Cygwin Project Co-Leader Red Hat