Re: gdb/gdbserver not responding with cygwin

[Doug Schaefer <DSchaefer at qnx dot com>]

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




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