Mail Archives: cygwin/2007/04/18/20:45:02
[added cygwin to CC list; note cygwinners: original newgroup is members
only, so replies will probably bounce. CDT folks, check
http://news.gmane.org/gmane.os.cygwin or
http://www.cygwin.com/ml/cygwin/2007-04/ ]
But my eclipse identity got bounced by cygwin's mail filters. So,
trying again, separately.
Doug Schaefer wrote:
> As with all things cygwin these days, they changed something that
> breaks the CDT and they don't care. We do have a bug open on that. I
> don't have the number handy, but it is a known problem that we'll have
> to figure out for CDT 4.
Doug, that's not a fair characterization. AFAIK, there are two main
issues with cygwin (well, any windows) gdb and CDT:
(1) Filename issues. For one thing, current gdb cvs has:
http://sourceware.org/ml/gdb-patches/2007-03/msg00291.html
So that problem may be going away. But I've a commentary on that.
(2) signal issues. Sigh. POSIX signals are not a good match for
windows, and the cygwin implementation is, well, the best we can do
under such circumstances. No offense to the people who've worked hard
on that part of cygwin, but it's not their fault: POSIX signals do not
map well to the native windows services. That's why win32-pthreads is,
err, not small:
ftp://sourceware.org/pub/pthreads-win32/prebuilt-dll-2-8-0-release/lib
And delivering *windows events* like CTRL-C (as opposed to posix
signals) to a native-windows target or to a cygwin target, well, that's
a whole 'nother ball of wax.
However, that having been said...because gcc, gdb/insight, and cygwin
all seem to work as expected in standalone mode, there's not much that
the cygwin developers can do. I don't know of anyone who has tried to
use gdbserver under cygwin...and from my investigation, it does not
appear that gdbserver was ever supported by an official cygwin gdb
release. It'd be great if it were, but...missing features are not bugs,
much as we'd like to see those features and have them work properly.
As a matter of policy, our limited developer time is focused on those
2GB worth of user packages that are actually part of the cygwin
distribution. We don't have the resources to ALSO fix compatibility
issues with third-party software, no matter how widely used, that is NOT
part of the cygwin distribution. Unless it uncovers an actual *bug*,
rather than "I was using this serendipitous undocumented feature last
week, and now it's gone".
There's a difference between "we don't care" and "we have to prioritize
limited resources" -- and as director of the CDT project, Doug, you know
the difference.
Of course, patches developed elsewhere will be gratefully considered,
and we don't deliberately TRY to break third party software (if we did,
there's a HELL of a lot of crud in cygwin1.dll I'd happily toss over the
side).
Of course, it's possible somebody might get even more help if they
submitted a proper bug report ( http://cygwin.com/problems.html, and
http://www.catb.org/~esr/faqs/smart-questions.html ), which we've yet to
see AFAICT.
=========
Now, concerning DOS-style paths. This was discussed (briefly) here
http://www.cygwin.com/ml/cygwin/2006-07/msg00257.html
It occurs to me, however, that the following is not obvious to someone
who is unversed in Eclipse/CDT -- but I've never seen it mentioned in
the complaints about "cygwin" and CDT: it is very very common for "you
guys" to use the MinGW compiler with the Cygwin debugger. THAT is not
an officially supported use case, even if it MAY have worked in the past
(and is probably the reason why cygwin-gdb gets confused by the
mingw-gcc-inserted C:-style paths).
Isn't there a mingw-supplied gdb? Shouldn't mingw-based CDT projects
use it, instead? And if that version of gdb is unsatisfactory,
shouldn't the complaints be directed to http://www.mingw.org, instead?
Plus, there's this from February: "[Patch] Win32 gdbserver new interrupt
support, and attach to process fix."
http://sourceware.org/ml/gdb-patches/2007-02/msg00294.html
and this
"[gdbserver] win32, add OUTPUT_DEBUG_STRING_EVENT handling."
http://sourceware.org/ml/gdb-patches/2007-02/msg00388.html
And there's this from last July
[rfa] Allow building a cross Cygwin / MinGW debugger
http://sourceware.org/ml/gdb-patches/2006-07/msg00237.html
and especially this from 18 Jul 2006:
RFC: Gdbserver for Windows
http://sourceware.org/ml/gdb-patches/2006-07/msg00239.html
"It doesn't have support for interrupts - pressing C-c in GDB won't stop
it. Leo and I had been talking about how to do that, but I'm afraid I've
run out of time for this project for now."
======
Note also that the latest gdb from cygwin is 06 Jul 2006, and the gdb
from mingw is 'current:20030511, contributed:20050924,
snapshot:20051117' -- which perhaps explains why many people are using
cygwin's gdb with mingw's compilers: our gdb is newer, even if both
projects' versions lag behind cvs HEAD and are missing ALL of the
patches above...
Now, on the other hand, if cygwin-gcc-based CDT projects using the
cygwin-provided gdb are having path issues, the first question I'd ask
is "why is cygwin-gcc putting DOS-style paths into the debug info" and
NOT "why can't cygwin-gdb understand DOS-style paths". Cause the former
is a *bug*, the second is a missing, and perhaps desired, feature.
Or, you could just ignore everything I've written, and we can fall back
the cygwin official motto: We're Just Mean(tm).
--
Chuck
--
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Problem reports: http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ: http://cygwin.com/faq/
- Raw text -