Re: gdb/gdbserver not responding with cygwin

[Charles Wilson <cygwin at cwilson dot fastmail dot fm>]

[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/