Re: cygwin1.dll - debug version (RE: similar crash in mmap for 1.5.3-1)

[Christopher Faylor <cgf-rcm at cygwin dot com>]

On Wed, Sep 10, 2003 at 11:40:33AM -0400, Igor Pechtchanski wrote:
>On Wed, 10 Sep 2003, Christopher Faylor wrote:
>>On Wed, Sep 10, 2003 at 01:23:56PM +0200, Hannu E K Nevalainen (garbage mail) wrote:
>>>>From: cygwin-owner@cygwin.com [mailto:cygwin-owner@cygwin.com]On Behalf
>>>>Of Christopher Faylor
>>>
>>><SNIP>
>>>>>Idea, to help debug things like the above:
>>>>>
>>>>>Alt 1) Make an _unstripped_ cygwin1.dll available in a package named
>>>>>"cygwin-DEBUG-dll" or some such.  Also make it be
>>>>"TEST/Exp" forever.
>>>>>Alt 2) Have an unstripped cygwin1-DEBUG.dll added to the basic package,
>>>>>add a simple "cygswapdll" utility.
>>>>>
>>>>>Is this a Good or Bad idea?
>>>>
>>>>The new version of binutils allows you to strip debug information and
>>>>put it in a separate file.  Then you can provide that file to gdb and
>>>>use it for debugging.
>>>
>>>Right, now that you mention it I remember seeing it.  My ideas ran
>>>obsolete already in the start ':-> .
>>>
>>>>However, like everything there are two problems 1) lack of tuit cycles
>>>>and 2) it won't stop people from running gdb on their binaries and
>>>>reporting that strdup is causing a problem in mmap.  There will still
>>>>be a "download the debug info" step no matter what.
>>>
>>>Most likely...  Some wording regarding "download the debug info" needs
>>>to be added to "problems.html" - I guess.
>>
>>That sort of presupposes that someone is interested in walking people
>>through the debugging of the cygwin DLL.  I know I'm not interested and
>>I haven't seen anyone else step in when people start asking debugging
>>questions.
>>
>>I guess the words in problems.html could be extended with a "You're
>>basically on your own"...
>>
>>This is not a bad idea, especially since I thought of it myself long
>>ago :-), like I said, it just requires some time which I don't have
>>right now.
>
>FWIW, I think Hannu has a point in that if debugging information were
>available, it would be much easier for people to step in and outline
>the necessary actions to provide a good stack trace than it would be to
>show them how to build a debug version of the DLL from scratch.  Just
>my 2c.

"This is not a bad idea...it just requires some time which I don't have
right now."

I haven't, so far, seen anyone chime in usefully on this issue when
people have provided stack traces.  There are other issues which would
crop up even if debugging info were available like the fact that traces
are unreliable where they include functions without stack frame info.

Also, the problems.html page is surely the wrong place for a tutorial
for how to debug the cygwin DLL.  A hyperlink to a page which talked
about this, with a caveat about this being only for the technically
savvy, would be fine.  But I'm not going to write it.  Volunteers?
--
Please use the resources at cygwin.com rather than sending personal email.
Special for spam email harvesters: send email to aaaspam@sourceware.org
and be permanently blocked from mailing lists at sources.redhat.com

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