From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 3456 invoked by alias); 10 Mar 2010 16:19:04 -0000 Received: (qmail 3437 invoked by uid 22791); 10 Mar 2010 16:19:02 -0000 X-SWARE-Spam-Status: No, hits=-2.6 required=5.0 tests=BAYES_00 X-Spam-Check-By: sourceware.org Received: from cernmx13.cern.ch (HELO cernmx13.cern.ch) (137.138.142.200) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Wed, 10 Mar 2010 16:18:53 +0000 Received: from cernfe13.cern.ch (137.138.140.38) by cernmxgwlb.cern.ch (137.138.142.200) with Microsoft SMTP Server (TLS) id 8.2.176.0; Wed, 10 Mar 2010 17:18:51 +0100 Received: from [192.168.1.53] (81.62.142.75) by smtp.cern.ch (137.138.140.59) with Microsoft SMTP Server (TLS) id 8.2.176.0; Wed, 10 Mar 2010 17:18:50 +0100 Subject: Re: No unwind info for __do_global_ctors_aux / _init? MIME-Version: 1.0 (Apple Message framework v1077) Content-Type: text/plain; charset="us-ascii" From: Lassi Tuura In-Reply-To: Date: Wed, 10 Mar 2010 16:19:00 -0000 CC: Content-Transfer-Encoding: 7bit Message-ID: <127E5791-E7CF-4E25-928A-AB2427E131C0@cern.ch> References: <7807360E-0CD1-4340-B876-C146ED5091BE@cern.ch> To: Ian Lance Taylor X-CERN-Reverse-DNS: cernfe13.cern.ch Mailing-List: contact gcc-help-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-help-owner@gcc.gnu.org X-SW-Source: 2010-03/txt/msg00148.txt.bz2 Hi, Thanks for your response. >> Is there any way to coax GCC to generate .eh_frame information for >> these functions? > > You could try modifying the gcc Makefile to add -funwind-tables or > -fasynchronous-unwind-tables to CRTSTUFF_CFLAGS. Thanks, I'll give that a go. >> I tried recompiling one library with and without >> -fasynchronous-unwind-tables on a RHEL5-derived system with GCC >> 4.3.4 + binutils 2.19.1, but didn't get the extra unwind info. In >> fact -fasynchronous-unwind-tables didn't make any difference that I >> could tell. > > -fasynchronous-unwind-tables should make a difference, and it is > required if you want to be able to reliably unwind the stack from a > signal handler. I'll try to debug what goes wrong here. FWIW, I don't want to unwind in the sense of throwing an exception, just trace the stack as well as reasonably possible. As it happens I haven't yet come across profile corruption because of this, I think, only other issues (e.g. epilogue). At any rate, it's a trade-off for us. We can live with a small fraction of corrupt stack traces. At the moment "small" is 10% which obviously isn't good enough. Some of this is issues in libunwind, not compiler. > By the way, if you aren't using mainline gcc I think you'll find that > the unwind information is incorrect in function epilogues, which means > that unwinding the stack from a signal handler will break if the > signal comes in as a function is returning. I think this may be fixed > in mainline. Yes, I discovered this and was reading through the patches the other day. Up to about to five percent of our stack traces are corrupted because of this. Unfortunately the system libraries (libc, libm) have this issue as well, which makes it rather thorny for us to fix. By "mainline" do you mean this isn't in any release yet? Hm, will have to try to pull those patches separately then. Regards, Lassi