Re: [RFA] win32-nat.c: Simplify generation of Windows environment

[Corinna Vinschen <vinschen@redhat.com>]

On Dec  8 09:31, Eli Zaretskii wrote:
> > Cc: gdb-patches@sourceware.org
> > From: Jim Blandy <jimb@codesourcery.com>
> > 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