This is the mail archive of the mailing list for the Cygwin project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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

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: []On Behalf
>>>>Of Christopher Faylor
>>>>>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
>>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 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 rather than sending personal email.
Special for spam email harvesters: send email to
and be permanently blocked from mailing lists at

Unsubscribe info:
Problem reports:

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]