From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 20096 invoked by alias); 4 Feb 2006 03:27:38 -0000 Received: (qmail 20087 invoked by uid 22791); 4 Feb 2006 03:27:37 -0000 X-Spam-Check-By: sourceware.org Received: from nevyn.them.org (HELO nevyn.them.org) (66.93.172.17) by sourceware.org (qpsmtpd/0.31.1) with ESMTP; Sat, 04 Feb 2006 03:27:34 +0000 Received: from drow by nevyn.them.org with local (Exim 4.54) id 1F5E5C-0002i2-EU for gdb-patches@sourceware.org; Fri, 03 Feb 2006 22:27:30 -0500 Date: Sat, 04 Feb 2006 03:27:00 -0000 From: Daniel Jacobowitz To: gdb-patches@sourceware.org Subject: Re: RFA: Support Windows extended error numbers in safe_strerror Message-ID: <20060204032730.GB9890@nevyn.them.org> Mail-Followup-To: gdb-patches@sourceware.org References: <20060203215455.GA3501@nevyn.them.org> <200602032325.k13NPJ6g028001@elgar.sibelius.xs4all.nl> <20060203233935.GA13238@trixie.casa.cgf.cx> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20060203233935.GA13238@trixie.casa.cgf.cx> User-Agent: Mutt/1.5.8i X-IsSubscribed: yes Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org X-SW-Source: 2006-02/txt/msg00055.txt.bz2 I have some general responses to this thread so far, which unfortunately hasn't addressed the actual patch at all but the overall goal of working on MinGW32 i.e. Windows-without-Cygwin. On Fri, Feb 03, 2006 at 06:39:35PM -0500, Christopher Faylor wrote: > On Sat, Feb 04, 2006 at 12:25:19AM +0100, Mark Kettenis wrote: > >I think this is ugly. When the win32 support was added, we were told > >that only minimal changes were necessary. But people keep pushing > >#ifdef EVIL_CLOSED_SOURCE_PLATFORM_FROM_REDMOND patches. > > > >GDB is written for POSIX systems. It's clear that Windows isn't even > >remotely POSIX compliant. I'm sorry you feel the need to use terms like "evil" to deal with a real operating system that real people use. I don't know who said "only minimal changes were necessary" but I'm sure they were making their best guess at the time. I don't know why you say that GDB was written for POSIX systems. I haven't been around long enough in GNU land and GDB land to know what it was "written for", but I'd wager from changelogs that GDB was written for SunOS and other proprietary OS's available at the time, and written with the eventual goal of working on GNU systems. Neither of which was a particularly good map onto what we now think of as POSIX. I'd say that GDB was written for the hosts that were interesting at the time. Many of which happened to have a BSD heritage. > Hmm. As it turns out, I have some email sitting in my "to be sent" > folder that I've held back on sending which is tangentially related > to this. > > The gist of the email is that I'm not happy having to support > windows-specific workarounds in gdb while standing on my head in > cygwin-land to make sure that as few workarounds as possible are needed > for programs like gdb. I'm going to make a couple of points here. They're mostly aimed at the GDB list, not at Chris - who's well aware of all of them already. 1. Cygwin is an amazing, and amazingly useful, piece of work. 2. Cygwin is not an FSF project. 3. Relying on Cygwin to support Windows is awkward for a whole lot of reasons, which are in many cases accepted as good ones, and I hope that I don't need to rehash right now. But I will if I have to. Just ask. That's why some people do it with Cygwin and some people do it without. CodeSourcery has both decided on our own (based on the technical merits) and heard unequivocally from our customers that relying on Cygwin just isn't going to cut it. What I'd _love_ to do is refactor the bits of Cygwin which we need, which are considerably smaller than the whole of Cygwin, so that we could link them directly into GDB and not have to worry about it any more. Given the copyright status of Cygwin, however, I think this is a non-starter. I'm not even sure whether it would fit into the design of Cygwin, or end up rewriting much of it anyway. It might be possible to create a minimalist set of POSIX wrapper functions for Windows which were nowhere near as complete as Cygwin, were built on top of mingw32, and were moderately more transparent to GDB. But I don't think they'd be of much general use besides for GDB, because there's real limits to how good an emulation you can manage without - surprise! - reinventing Cygwin! See #1 above, please. > I'm concerned that the MinGW patches are going to eventually start > encroaching on win32-nat.c (which we've already seen). I don't *want* > to litter that file with any special non-cygwin accommodations. How bad do you really expect this to be? I've never seen the native MinGW debugging patches; I don't intend to take a look at them, since right now we (i.e. in my day job) only need Windows hosting and not Windows native debugging. But I'd expect that changes would either be small (if done right), or else relatively easy to break out into a separate file using this neat target inheritance concept we put so much effort into. The question of Windows support is not going to go away at any point in the foreseeable future. If the GDB community is going to throw up its hands and say ugh, well, I'd be pretty disappointed. And CodeSourcery would be maintaining a branch with these patches for all of that foreseeable future, and shipping it. We're trying as hard as we can to not do that - it's not good for us, it's not good for GDB, it's not good for users who would like to build GDB releases on Windows. I'm sorry a lot of you find the changes either morally or aesthetically objectionable. I'm not entirely sure which it is. -- Daniel Jacobowitz CodeSourcery