This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
Re: [RFA] win32-nat.c: Simplify generation of Windows environment
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