This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
Re: RFA: Support Windows extended error numbers in safe_strerror
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