X-Recipient: archive-cygwin AT delorie DOT com
X-SWARE-Spam-Status: No, hits=-0.7 required=5.0	tests=AWL,BAYES_00,SPF_NEUTRAL
X-Spam-Check-By: sourceware.org
Message-ID: <4F5DE96B.3080105@cs.utoronto.ca>
Date: Mon, 12 Mar 2012 08:17:47 -0400
From: Ryan Johnson <ryan DOT johnson AT cs DOT utoronto DOT ca>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2
MIME-Version: 1.0
To: cygwin AT cygwin DOT com
Subject: Re: Unfolding the stack
References: <6BFA9AF2C7556E42AFF3F187ECAB07B802DAFBAB AT bespdc01 DOT mediaxim DOT local>
In-Reply-To: <6BFA9AF2C7556E42AFF3F187ECAB07B802DAFBAB@bespdc01.mediaxim.local>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-IsSubscribed: yes
Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm
List-Id: <cygwin.cygwin.com>
List-Subscribe: <mailto:cygwin-subscribe AT cygwin DOT com>
List-Archive: <http://sourceware.org/ml/cygwin/>
List-Post: <mailto:cygwin AT cygwin DOT com>
List-Help: <mailto:cygwin-help AT cygwin DOT com>, <http://sourceware.org/ml/#faqs>
Sender: cygwin-owner AT cygwin DOT com
Mail-Followup-To: cygwin AT cygwin DOT com
Delivered-To: mailing list cygwin AT cygwin DOT com


On 12/03/2012 5:39 AM, Michel Bardiaux wrote:
> To complete the port of some library to Cygwin, I need a way to produce
> a traceback with as much info as possible. Currently I have something
> that works but not that well.  There are basically 3 parts:
>
> * Gather all the stack frames; see below.
> * Assign the PCs in each frame to some executable image; done via dlfcn.
> To be discussed later.
> * Convert the PCs to function+source+line; done via addr2line. Ditto.
>
> Despite a lot of web digging I have not (yet?) found a better way than
> this classic unixish song-and-dance:
>
> [...
>       snipped source that manually parses output
>       of forked child's call to cygwin_stackdump()
> ...]
>
> Now this is acceptable for a traceback following the raising of some
> error condition, but seems much too heavy for using in a leak detector.
> Does anyone know of an equivalent API under cygwin? Or could we consider
> adding such a variation of cygwin_stackdump to the cygwin DLL?
This is hard in C, and harder in code compiled by gcc due to things like 
-fomit-frame-pointer and gcc's tendency to use alloca under the hood for 
large stack allocations. This is nothing unique to cygwin, but it does 
mean that cygwin's stack dumper is unsafe to use because it may get 
something wrong and go to la-la-land. This seems to work ok-ish during 
error-before-abort but not for code that hopes to continue running 
reliably after the call.

If you're using C++, and if exceptions are enabled, then you could use 
gcc's <unwind.h> to non-destructively unwind any stack frame that an 
exception might propagate through/into. Unfortunately, interesting 
functions don't always get unwind info, and traversing one of those can 
cause seg faults during unwinding. Also unfortunately, this trick seems 
broken in the latest version of cygwin/gcc on my machine (the example I 
developed a while back under linux seg faults).

Alternatively, you could compile with -g and try to traverse the debug 
info tables gdb uses to work around everything nasty gcc does, but 
there's no clean API there that I know of.

Out of curiosity, what is your library currently using to generate 
backtraces? There's a backtrace facility in glibc (man backtrace), but 
it's got a long list of caveats as well, including death by 
-fomit-frame-pointer (it doesn't use any debug/unwind info emitted by 
the compiler).

Ryan




--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple