X-Recipient: archive-cygwin AT delorie DOT com X-SWARE-Spam-Status: No, hits=-1.4 required=5.0 tests=AWL,BAYES_00,T_RP_MATCHES_RCVD X-Spam-Check-By: sourceware.org MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-class: urn:content-classes:message Subject: FW: Unfolding the stack Date: Mon, 12 Mar 2012 16:20:39 +0100 Message-ID: <6BFA9AF2C7556E42AFF3F187ECAB07B802DAFBF3@bespdc01.mediaxim.local> From: "Michel Bardiaux" To: X-IsSubscribed: yes Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm List-Id: 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 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by delorie.com id q2CFLQSR008834 [snip] > This is hard in C, and harder in code compiled by gcc [snip] I know that, and am willing to accept the risk since any info is better than none. I just wish for a more efficient mechanism than I am now using. > If you're using C++, [snip] Nope. > 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. Since cygwin_stackdump does not dare to tread there... > Out of curiosity, what is your library currently using to generate backtraces? Well you just snipped it: pipe/fork/dup to catch the stderr of cygwin_stackdump called in the forked process. > 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). In what package? I have cygwin basics + gcc installed, and no backtrace in any .h. -- 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