Re: Windows support in GDB

Christopher Faylor
2005-04-29T16:52:09Z

On Fri, Apr 29, 2005 at 09:43:35AM -0700, Mark Mitchell wrote:
>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.

For now. Didn't you just theorize more involvement from the MinGW
community now that your patch is in?

I have to admit that I've got incredibly mixed feelings about this.
After years of asking for patches, I'm happy that they are finally in.
Now I find myself mildly dreading the support aspect.

But, I guess we can see how it goes.

>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.
>
>What's the failure mode going to be? If a POSIX person adds a use of
>non-Windows function, without appropriate #ifdef, then the Windows side
>of things will break. At that point, assuming that people are noticing
>(which we will!), we'll fix that.

I guess the failure mode will be roughly similar to DJGPP. Every time
someone decides that it would be nice to use signal(), select(), fifos,
inodes, unix-domain sockets, or some other non-msdos construct there
will have to be a discussion about how to make things work. But, I
guess we'd already be having this discussion to with DJGPP so maybe it
won't be a big deal.

>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.

No, but maybe we should rewrite gdb in c++. That sounds like it would
solve everything. :-)

cgf