[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[news.eclipse.tools.cdt] Re: gdb/gdbserver not responding with cygwin
Charles Wilson wrote:
[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/ ]

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:

That's true. I've been frustrated with trying to get cygwin tools working with CDT and unfortunate let my emotions get the best of me :). I apologize.

(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.


I think that's the main issue we're running into with gdb at least. There is a bug in the CDT database where we are discussing alternatives.

https://bugs.eclipse.org/bugs/show_bug.cgi?id=179150

In the end, I think we need to handle the cygwin environment as a specific host type and ensure our integrations know about it. That way we can continue to interact with Windows tools as they need and cygwin tools as they need.


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.

gdbserver is very linux specific. I think the issue is arising from running cygwin gdb to connect to a gdbserver on a remote linux machine. But we are having similar issues just running gdb locally.

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".

Agreed. But, in the end it is really up to the greater community to work on a solution, if one is so desired. I certainly don't expect the cygwin maintainers to ensure the CDT works with their tools.

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.

I certainly do and again apologize for the remark. I think what I'm really trying to say is that the work you guys are doing to better support your packages is making it more difficult for Windows-based tools, such as Eclipse and the CDT, to interact with them. So in that sense, I am agreeing with you that you have much higher priorities than supporting us.

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).

Actually the file path issue came up in a recent release of cygwin make where DOS file paths are no longer supported. That is a separate issue from the gdb one mentioned.

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?

Of course there is a mingw-based gdb and, yes, it has issues and those issues will be raised there. I don't think the original author of this thread was using a mingw-based toolchain, though. My mention of it was just a response to him as an update on what I'll be working on and not meant for the cygwin list.

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...

Yes, I need to find out what's happening with mingw's gdb. It does seem to be stale and in need of attention.

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).

I wouldn't do that :). Thanks for the reply. I think in the end the CDT and cygwin communities need to work closer together, especially those that are trying to use both. People are assuming that these two should just work with no extra effort, but as we both know, Windows is a tough environment to get tools working in and both projects could use the help.

Cheers,
Doug

--
Chuck