Re: Windows support in GDB

[Christopher Faylor <me@cgf.cx>]

On Fri, Apr 29, 2005 at 11:31:46AM -0400, Daniel Jacobowitz wrote:
>Hi Mark,
>
>On Fri, Apr 29, 2005 at 05:13:43PM +0200, Mark Kettenis wrote:
>> Guys, I'm getting a bit of an uneasy feeling here.  It may be that I'm
>> getting the wrong impression here, but I've seen quite a bit more
>> Windows-related patches than I had in mind when Mark started submitted
>> his first patches and said they were fairly limited and mostly some
>> configure bits.  The problem here is that they mostly concern the
>
>Paul's new patches are issues that we didn't encounter when we built
>our first generation of Windows toolchains.  I apologize for our
>failures to be perfect and predict the future.  What more can you ask
>of us?
>
>By the way, I'd still characterize these patches as fairly limited and
>mostly configure-related.  All the readline patches certainly are, for
>instance.
>
>The SIGTRAP patch makes me a little uncomfortable - and it makes Paul
>a bit nervous too.  That's why it wasn't submitted for mainline.  The
>right fix is to not use host signal numbers in the simulator interface.
>
>> non-POSIX nature of Windows, which sets its quit far apart from the
>> traditional Unix-like systems that have been converging towards POSIX
>> for quite some time now.  This means that we really need to have some
>> commitment from the Windows user community for maintaining this stuff.
>> Otherwise this will become another MetroWerks disaster.
>
>I don't know what you're referring to.  Are you thinking of the HP
>merge?
>
>>It's fairly obvious that this development is coming from CodeSourcery.
>>There's nothing wrong with that, but I'd like to ask CodeSourcery what
>>their commitment to maintaining this new code is.  In the past we have
>>seen quite a few contributions from embedded sofware companies.  In
>>many cases these contributions were apparently done as contract work,
>>and after the work was completed the code was never touched again.  Can
>>CodeSourcery gives some clarification on this matter?
>
>We have a strong push from our customers - not just any one customer -
>for these features.  These are ongoing maintenance contracts and we
>will be continuing to support it for the foreseeable future.  Also, I
>imagine that once GDB starts to build out of the box on Windows, more
>and more people will begin to use it there.  There's a staggering
>demand for native Windows-hosted tools.

Of course it does build "out of the box" on Windows right now if you
have cygwin.

While I am the Windows maintainer for gdb, I have been thinking that
maybe I might have to step down if it means that I'll have to support a
Windows configuration for which I have little interest.

I haven't asked what the problem is with just using cygwin with gdb.
I suspect that the standard two problems are:

1) cygwin is "slow" (which really only is an issue for configure/make)

and

2) You can't trivially include your own version of cygwin1.dll with
a distribution since it could conflict with a version already on
the system.

I can't do much to address 1 but 2 is not an insurmountable problem.

cgf