From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 79613 invoked by alias); 15 Mar 2016 16:38:48 -0000 Mailing-List: contact gcc-patches-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-patches-owner@gcc.gnu.org Received: (qmail 77593 invoked by uid 89); 15 Mar 2016 16:38:47 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.9 required=5.0 tests=BAYES_00,RP_MATCHES_RCVD,SPF_PASS,UNPARSEABLE_RELAY autolearn=ham version=3.3.2 spammy=Hx-languages-length:1342, exclusively, H*MI:oracle X-HELO: aserp1040.oracle.com Received: from aserp1040.oracle.com (HELO aserp1040.oracle.com) (141.146.126.69) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES256-GCM-SHA384 encrypted) ESMTPS; Tue, 15 Mar 2016 16:38:46 +0000 Received: from aserv0021.oracle.com (aserv0021.oracle.com [141.146.126.233]) by aserp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id u2FGcglR026182 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 15 Mar 2016 16:38:43 GMT Received: from userv0121.oracle.com (userv0121.oracle.com [156.151.31.72]) by aserv0021.oracle.com (8.13.8/8.13.8) with ESMTP id u2FGcf3s024405 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 15 Mar 2016 16:38:42 GMT Received: from abhmp0016.oracle.com (abhmp0016.oracle.com [141.146.116.22]) by userv0121.oracle.com (8.13.8/8.13.8) with ESMTP id u2FGceY6019404; Tue, 15 Mar 2016 16:38:41 GMT Received: from termi.oracle.com (/10.211.47.3) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Tue, 15 Mar 2016 09:38:39 -0700 From: jose.marchesi@oracle.com (Jose E. Marchesi) To: Eric Botcazou Cc: gcc-patches@gcc.gnu.org Subject: Re: [PATCH][SPARC] sparc: switch -fasynchronous-unwind-tables on by default. References: <1456435447-23676-1-git-send-email-jose.marchesi@oracle.com> <10333302.PFiANu1Ugm@polaris> <87h9grcy85.fsf@oracle.com> <6828458.u3IJH91KbV@polaris> Date: Tue, 15 Mar 2016 16:38:00 -0000 In-Reply-To: <6828458.u3IJH91KbV@polaris> (Eric Botcazou's message of "Wed, 09 Mar 2016 11:02:53 +0100") Message-ID: <87pouvk7th.fsf@oracle.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-IsSubscribed: yes X-SW-Source: 2016-03/txt/msg00849.txt.bz2 > Consider the attached test program. When built with -g in sparc64-*-* > the resulting binary contains: > > - A .eh_frame segment containing CFA information for __libc_csu_init and > __libc_csu_fini. > > - A .debug_frame segment containing CFA information for func2, func1 and > main. > > The backtrace(3) implementation for sparc contains a simple unwinder > that works well in most cases, but that unwinder is not used if > libgcc_s.so can be dlopened and it provides _Unwind_Backtrace. Now, > _Unwind_Backtrace uses .eh_frame but not .debug_frame. Thus, > backtrace(3) is only useful in programs built with > -fasynchronous-unwind-tables even if -g provides CFA info in > .debug_frame. How does that work for e.g. PowerPC or MIPS? Why not do the same for SPARC? The glibc PowerPC port doesn't use the libgcc_s unwinder to implement backtrace(). It has a little ad-hoc unwinder. MIPS is like x86_64: it exclusively relies on libgcc_s _Unwind_Backtrace to unwind the stack. As far as I can tell, -fasynchronous-unwind-tables is disabled in MIPS by default. Therefore unless -fasynchronous-unwind-tables is used at build time backtrace() probably has the same problem than sparc (can't tell for sure, as I don't have access to any mips host where to test).