This is the mail archive of the mailing list for the GDB project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [RFA] testsuite: Add a test for passing of environment variables to inferior

On Oct  4 16:49, Pierre Muller wrote:
> > De : [mailto:gdb-patches-
> >] De la part de Corinna Vinschen
> > Yes, that would be necessary.  I'm wondering if we can't just utilze the
> > global environ variable for this and spare us all the hassle.  Something
> > along these lines:
> > 
> >   char **old_env = environ;
> >   environ = in_env;
> >   cygwin_internal (CW_SYNC_WINENV);
> >   CreateProcessW (NULL environment pointer);
> >   environ = old_env;
>   I checked it out, but it still
> fails for the last test, the missing TEST_GDB_VAR1
> variable doesn't get removed from GDB environment list
> apparently (This is probably related to the internals
> of cygwin_internal (CW_SYNC_WINENV), no?

Right.  The problem is that there's no simple Win32 call to set (or
clear) the Windows environment in one go.  So CW_SYNC_WINENV only sets
but never unsets because that would require to check each Windows
variable if it exists in the POSIX env or not.  That was more effort
than seemed to make sense at the time.

>   Manually resetting all variables should help...

Yes, but that's far from elegant.  I don't mean your patch, but the fact
that it seems to be necessary at all.  Maybe we should introduce some
new cygwin_internal call, which produces a Win32 environment from a
POSIX environment without affecting the Win32 environment of the calling

  LPWCH out_env = (LPWCH) cygwin_internal (CW_CREATE_WIN32_ENV, in_env);
  CreateProcess (..., CREATE_UNICODE_ENVIRONMENT, ..., out_env, ...);
  free (new_env);

But that would only work for newer Cygwin releases, so that's just
a future option.

> The patch below does not generate any failure on my test,
> but I am still not sure what happens if you try to
> remove an environment variable that was set when GDB started...

GDB should not be affected.  Its POSIX environment is still intact and
that's all what's used when interacting with the underlying Cygwin POSIX
calls.  The only variable which should have an effect is $PATH, and that's
restored by the final cygwin_internal(CW_SYNC_WINENV) call.  So, AFAICS,
your patch should be fine.


Corinna Vinschen
Cygwin Project Co-Leader
Red Hat

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]