From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 15580 invoked by alias); 29 Apr 2005 16:04:01 -0000 Mailing-List: contact gdb-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sources.redhat.com Received: (qmail 12214 invoked from network); 29 Apr 2005 16:00:40 -0000 Received: from unknown (HELO cgf.cx) (66.30.17.189) by sourceware.org with SMTP; 29 Apr 2005 16:00:40 -0000 Received: by cgf.cx (Postfix, from userid 201) id 9BD7813C1C8; Fri, 29 Apr 2005 12:00:40 -0400 (EDT) Date: Fri, 29 Apr 2005 16:08:00 -0000 From: Christopher Faylor To: mark@codesourcery.com, paul@codesourcery.com, gdb@sourceware.org Subject: Re: Windows support in GDB Message-ID: <20050429160040.GH10017@trixie.casa.cgf.cx> Mail-Followup-To: mark@codesourcery.com, paul@codesourcery.com, gdb@sourceware.org References: <200504291513.j3TFDhjx021040@elgar.sibelius.xs4all.nl> <20050429153146.GA27362@nevyn.them.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050429153146.GA27362@nevyn.them.org> User-Agent: Mutt/1.5.8i X-SW-Source: 2005-04/txt/msg00218.txt.bz2 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