From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 3970 invoked by alias); 5 Feb 2006 22:44:18 -0000 Received: (qmail 3961 invoked by uid 22791); 5 Feb 2006 22:44:17 -0000 X-Spam-Check-By: sourceware.org Received: from cgf.cx (HELO cgf.cx) (24.61.23.223) by sourceware.org (qpsmtpd/0.31) with ESMTP; Sun, 05 Feb 2006 22:44:16 +0000 Received: by cgf.cx (Postfix, from userid 201) id EC2F113C0F8; Sun, 5 Feb 2006 17:44:14 -0500 (EST) Date: Sun, 05 Feb 2006 22:44:00 -0000 From: Christopher Faylor To: gdb-patches@sourceware.org Subject: Re: RFA: Support Windows extended error numbers in safe_strerror Message-ID: <20060205224414.GA9733@trixie.casa.cgf.cx> 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> <20060204032730.GB9890@nevyn.them.org> <200602041435.k14EZ6NK016329@elgar.sibelius.xs4all.nl> <20060205001503.GB8728@trixie.casa.cgf.cx> <20060205193440.GB4718@trixie.casa.cgf.cx> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.11 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/msg00109.txt.bz2 On Sun, Feb 05, 2006 at 10:19:12PM +0200, Eli Zaretskii wrote: >> Date: Sun, 5 Feb 2006 14:34:40 -0500 >> From: Christopher Faylor >> >> On Sun, Feb 05, 2006 at 06:46:06AM +0200, Eli Zaretskii wrote: >> >>Date: Sat, 4 Feb 2006 19:15:03 -0500 >> >>From: Christopher Faylor >> >> > >I don't know if that's a show-stopper: I don't use Cygwin. !!! >But if Cygwin users frequently have a development environment without a >shell (which I doubt is the case), then yes, having a workable `shell' >command without Bash would be a good change. I'm not sure how this was misconstrued but I wasn't asking for your advice about the Cygwin development environment. I was referring to the minimal environment that I was mentioning. By listing the DLLs required to run gdb, I thought that it would show that you don't need a whole cygwin distribution if you want to debug your MinGW-based applications. >> >Second, running GDB alone is not useful. People use the Cygwin build >> >of GDB to debug other Cygwin programs. Just building those other >> >programs requires a more or less full Cygwin installation, including >> >the shell, Coreutils, Grep, Gawk, and whatsnot. >> >> You've lost me. So people *do* (because they can) download a lot of >> other packages along with gdb so that means that gdb is unacceptable as >> a native debugger? > >I didn't say that; please re-read the wording you quoted. I said: > > But it isn't the same platform, anymore than MIPS/Linux and MIPS/Irix > are the same platform. Cygwin requires a considerable amount of > additional software to be installed, of which a large part is a system > library that presents a very different API than the native OS. > >So this was in the context of discussing the ``2 ports on the same >platform'' issue, not GDB being run alone. I'm saying that a Cygwin >development environment changes the OS to a degree that it isn't the >same system anymore. You were arguing that Cygwin "isn't the same platform" as Windows. I am arguing that, as far as GDB is concerned, the distinction is meaningless. (It really is pretty much meaningless in general, but that is a separate issue) If you want to develop programs for any platform then, *of course* you need the compilers and any supporting software necessary. If you only want to compile programs, the software requirements for Cygwin and MinGW are pretty much the same. Once you start moving into the realm of complicated autoconf-based packages you leave MinGW behind (by its very nature) so the distinction is pointless. So, a development environment for MinGW could just consist of the MinGW version of gcc, the MinGW version of make, and the Cygwin version of gdb plus a few dlls. Given the number of auxilliary files that are installed with gcc, I don't see how anyone could really complain about the addition of a few extra files with gdb.exe. >As another data point, consider this: Emacs now supports a Cygwin >build as well as a native Windows build (either with MinGW or MSVC). >The amount of Windows-specific code that is common to those two ports >is close to nil. Until the time that Cygwin implements ptrace or some other UNIX-alike debugging scheme, a native windows debuger will use the low-level Windows-specific API for debugging (which is actually, IMO, a pretty nice interface). gdb is different than 'gcc' or 'make' or most other programs because it is not possible to easily hide OS differences with wrapper functions. The majority of the code in win32-nat.c is not cygwin-specific. It's just there to plug the Windows debugging API into gdb. So, drawing analogies with emacs or most other programs is meaningless. >>If you're talking about trying to run programs under bash, then, the >>only problem that I can think of is what Daniel found - some native >>Windows programs misbehave if used with Cygwin's ttys or ptys. The >>solution to this dilemma is the same that you'd use if Cygwin was not >>on the system - don't use ptys or ttys. If you are a purist, then >>don't use bash. Just run gdb directly. >> >>I am not aware of any problems with running native windows programs >>under gdb. If there are, then I'd be happy to look into fixing them >>for as long as I continue to be maintainer. > >I'm talking about ttys and ptys. I'm talking about Ctrl-C. Aha! Details. Ctrl-C is not an issue for running windows programs in gdb. >I'm talking about incompatible quoting of command-line arguments and >&&. Don't know what "&&" is but the quoting of command-line arguments in Cygwin is supposed to mimic MSVCRT. I'm sure that we didn't get it entirely right wrt things like quoting quotes, however. And, getting it 100% compliant is not a huge goal for the project. It's difficult to accept patches for it since understanding the quoting rules is not easy and so you can't trust that random-Joe-patcher got it right. Luckily, this is not an issue for gdb since gdb passes arguments verbatim. >I'm talking about mount points and text/binary I/O. Not an issue for native windows programs. Certainly not an issue for programs run by gdb. (And, I'm wondering how anyone can think that Cygwin's mount points could impact windows programs. Maybe it's spooky action at a distance.) >Perhaps all this was solved in recent versions of Cygwin, I'm just >repeating what I hear from Cygwin users around me. Which is why I >didn't want to repeat that hearsay, but you left me no choice. !!! >Anyway, this discussion obviously doesn't lead to any constructive >direction, so I suggest we drop it. Our disagreements about this were >not born yesterday. Let's concentrate on the common goals, not on >disagreements. I would love to get off the treadmill, yes. I was just trying to understand your objections to using the Cygwin-based gdb as the one-and-only windows implementation in gdb. Now I do. AFAICT, your objections are, for the most part, not based on fact. cgf