From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 28108 invoked by alias); 28 Apr 2009 18:19:03 -0000 Received: (qmail 28100 invoked by uid 22791); 28 Apr 2009 18:19:02 -0000 X-SWARE-Spam-Status: No, hits=-1.7 required=5.0 tests=AWL,BAYES_00,SPF_HELO_PASS,SPF_PASS X-Spam-Check-By: sourceware.org Received: from mx1.redhat.com (HELO mx1.redhat.com) (66.187.233.31) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Tue, 28 Apr 2009 18:18:54 +0000 Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.13.8/8.13.8) with ESMTP id n3SIHVit027634; Tue, 28 Apr 2009 14:17:31 -0400 Received: from gateway.sf.frob.com (vpn-12-158.rdu.redhat.com [10.11.12.158]) by int-mx1.corp.redhat.com (8.13.1/8.13.1) with ESMTP id n3SIHLl6022276; Tue, 28 Apr 2009 14:17:29 -0400 Received: from magilla.sf.frob.com (magilla.sf.frob.com [198.49.250.228]) by gateway.sf.frob.com (Postfix) with ESMTP id 87BD5357B; Tue, 28 Apr 2009 11:17:20 -0700 (PDT) Received: by magilla.sf.frob.com (Postfix, from userid 5281) id 4CBECFC3C6; Tue, 28 Apr 2009 11:17:20 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit From: Roland McGrath To: Prerna Saxena Cc: Mark Wielaard , systemtap@sourceware.org Subject: Re: [Query] Re: dwarf unwinder (only works on i386/x86_64) In-Reply-To: Prerna Saxena's message of Tuesday, 28 April 2009 23:34:54 +0530 <49F74546.8040206@linux.vnet.ibm.com> References: <1239977157.2336.33.camel@fedora.wildebeest.org> <49F74546.8040206@linux.vnet.ibm.com> Message-Id: <20090428181720.4CBECFC3C6@magilla.sf.frob.com> Date: Tue, 28 Apr 2009 18:19:00 -0000 X-IsSubscribed: yes Mailing-List: contact systemtap-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Post: List-Help: , Sender: systemtap-owner@sourceware.org X-SW-Source: 2009-q2/txt/msg00463.txt.bz2 > I was trying to contrast the ".eh_frame" vs ".debug_frame" > specifications for keeping track of stack backtraces. Both appear rather > similar wrt information they maintain. .debug_frame format is that specified in the formal DWARF standard. .eh_frame format is a slight variant of that format, optimized for being used by a process itself without address fixups. (It is used by C++ exception handling, the backtrace() function, and so forth.) > The Exception header ".eh_frame" section seems to be present in vmlinux > even when kernel is compiled without debuginfo. This depends on lots of details of the kernel build that vary across versions and machines. In today's kernels, it is not usually there. > i. what gcc flags cause this section to be compiled ? -funwind-tables and similar options. > ii. This section seemingly appears to be a better bet than DWARF to base > the unwinder on--- because a ".debug_frame" based unwinder might not be > useful in case of a kernel complied without debuginfo. It is a somewhat hairy subject. But in short, this is not so in current kernels. That is not entirely apropos, because it's only the situation for the kernel, and there are also user binaries to consider. There it is an even more complex subject. The overall answer is that the answer is complex, but potentially both sections are involved. Thanks, Roland