This is the mail archive of the
gdb@sources.redhat.com
mailing list for the GDB project.
Re: Windows support in GDB
- From: "Eli Zaretskii" <eliz at gnu dot org>
- To: Mark Mitchell <mark at codesourcery dot com>
- Cc: me at cgf dot cx, paul at codesourcery dot com, gdb at sourceware dot org
- Date: Sun, 01 May 2005 22:46:17 +0300
- Subject: Re: Windows support in GDB
- References: <200504291513.j3TFDhjx021040@elgar.sibelius.xs4all.nl> <20050429153146.GA27362@nevyn.them.org> <20050429160040.GH10017@trixie.casa.cgf.cx> <42725D6A.7040103@codesourcery.com> <20050429162732.GA12864@trixie.casa.cgf.cx> <42726437.9050208@codesourcery.com>
- Reply-to: Eli Zaretskii <eliz at gnu dot org>
> Date: Fri, 29 Apr 2005 09:43:35 -0700
> From: Mark Mitchell <mark@codesourcery.com>
> CC: paul@codesourcery.com, gdb@sourceware.org
>
> Christopher Faylor wrote:
>
> > However, now that the patches are finally here, I have to say that I
> > sort of share Mark K's concerns. I'm wondering if we are on a slippery
> > slope and (to mix a metaphor) will be subjecting gdb to a
> > death-by-inches as we slowly add ifdefs throughout the configury and
> > code.
>
> I think it's a funny time to get concerned -- we're done. :-) There are
> no more cuts coming, so as long as we're not bleeding to death yet,
> we're not going to die. Plenty of GNU software has similar patches to
> support running on MinGW. GDB itself already has 2500 lines of code in
> win32-nat.c, some of which I would imagine is rather more opaque to
> POSIX programmers than anything we've added.
>
> We made these changes with no algorithmic modifications to GDB, no
> perversions of its core design, etc.
FWIW, I agree with Mark M. here: the changes added to support MinGW
were minimal, almost unnoticed in the sources.
> I certainly don't think the entire codebase will be littered with
> HANDLEs and ReadFileEx, or transformed into a multi-threaded application
> with a Windows event loop in the middle of it, or anything like that.
Perhaps we should have a mingw.c file to hide any such code, should
there be a need in the future. Not that I see a need for that now,
except maybe to put there the gdb_select emulation.