From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 24359 invoked by alias); 4 Oct 2011 10:40:51 -0000 Received: (qmail 24345 invoked by uid 22791); 4 Oct 2011 10:40:50 -0000 X-SWARE-Spam-Status: No, hits=-2.3 required=5.0 tests=AWL,BAYES_00,RP_MATCHES_RCVD X-Spam-Check-By: sourceware.org Received: from fencepost.gnu.org (HELO fencepost.gnu.org) (140.186.70.10) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Tue, 04 Oct 2011 10:40:36 +0000 Received: from eliz by fencepost.gnu.org with local (Exim 4.71) (envelope-from ) id 1RB2QN-0003Qv-81; Tue, 04 Oct 2011 06:40:35 -0400 Date: Tue, 04 Oct 2011 10:40:00 -0000 Message-Id: From: Eli Zaretskii To: "Pierre Muller" CC: gdb-patches@sourceware.org In-reply-to: <004801cc827b$e752bfd0$b5f83f70$@muller@ics-cnrs.unistra.fr> (pierre.muller@ics-cnrs.unistra.fr) Subject: Re: [RFC] Environment variables passed to inferior for Cygwin build ( follow up on mingw fix for PR 10989) Reply-to: Eli Zaretskii References: <4E7FBF9E.20000@earthlink.net> <20110926171511.GJ17681@adacore.com> <20111004075325.GB13895@calimero.vinschen.de> <004801cc827b$e752bfd0$b5f83f70$@muller@ics-cnrs.unistra.fr> 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: 2011-10/txt/msg00070.txt.bz2 > From: "Pierre Muller" > Date: Tue, 4 Oct 2011 11:56:35 +0200 > > But, after looking into it, I suspect that your proposal > was about setting only environment variables that have > been explicitly modified within GDB... but the environment list is a > simple array of 'char *'. > Furthermore, there is no recording inside GDB code of > environment variables that were explicitly modified. > in_env contains all environment variables coming from GDB startup. > > Thus, if I use your suggestion, > call cygwin_internal (CW_SYNC_WINENV); first > and set environment variables after, > PATH variable stays in cygwin form, which leads to a failure within > CreateProcess call because some DLLs are not found. > > Using cygwin_internal (CW_SYNC_WINENV); > after settings individual environment variables > using SetEnvironmentVariable call > work, but I am not sure this is what you wanted. > > I am still sending here the patch, so you can test it, if you want. > In fact, I suppose that the out_env part is not really needed: > if no environment pointer is given, CreateProcess takes the environment of > the parent process (which is GDB!), but we just modified it > so that probably, leaving that part out would give the same result. I'm confused: what problem(s) are you trying to fix in your patch? Can you please enumerate the problems, and why do you think they exist? I think there's a misunderstanding here (I thought that about the previous discussion in April, and I fear we will just repeat the same misunderstanding now). To comment on the part of what you say that I do understand: using SetEnvironmentVariable in this case is not TRT, because that changes the environment of GDB itself. By contrast, "set environment" and "unset environment" commands are supposed to affect only the environment of the inferior, without any effect on GDB itself. That is why I didn't use SetEnvironmentVariable in my patch.