Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm List-Subscribe: List-Archive: List-Post: List-Help: , Sender: cygwin-owner AT cygwin DOT com Mail-Followup-To: cygwin AT cygwin DOT com Delivered-To: mailing list cygwin AT cygwin DOT com Date: Wed, 10 Sep 2003 12:00:07 -0400 From: Christopher Faylor To: cygwin AT cygwin DOT com Subject: Re: cygwin1.dll - debug version (RE: similar crash in mmap for 1.5.3-1) Message-ID: <20030910160007.GC29506@redhat.com> Reply-To: cygwin AT cygwin DOT com Mail-Followup-To: cygwin AT cygwin DOT com References: <20030909172619 DOT GC4830 AT redhat DOT com> <20030910153228 DOT GB29506 AT redhat DOT com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.1i Note-from-DJ: This may be spam 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 AT cygwin DOT com [mailto:cygwin-owner AT cygwin DOT com]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 >>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 AT sourceware DOT 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/