From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 23509 invoked by alias); 17 Apr 2009 14:06:13 -0000 Received: (qmail 23492 invoked by uid 22791); 17 Apr 2009 14:06:11 -0000 X-SWARE-Spam-Status: No, hits=-2.1 required=5.0 tests=AWL,BAYES_00,SPF_HELO_PASS,SPF_PASS X-Spam-Check-By: sourceware.org Received: from mx2.redhat.com (HELO mx2.redhat.com) (66.187.237.31) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Fri, 17 Apr 2009 14:06:03 +0000 Received: from int-mx2.corp.redhat.com (int-mx2.corp.redhat.com [172.16.27.26]) by mx2.redhat.com (8.13.8/8.13.8) with ESMTP id n3HE61oQ008749 for ; Fri, 17 Apr 2009 10:06:01 -0400 Received: from ns3.rdu.redhat.com (ns3.rdu.redhat.com [10.11.255.199]) by int-mx2.corp.redhat.com (8.13.1/8.13.1) with ESMTP id n3HE60OO017146 for ; Fri, 17 Apr 2009 10:06:00 -0400 Received: from [10.32.10.26] (vpn-10-26.str.redhat.com [10.32.10.26]) by ns3.rdu.redhat.com (8.13.8/8.13.8) with ESMTP id n3HE5vg7016326 for ; Fri, 17 Apr 2009 10:05:58 -0400 Subject: dwarf unwinder (only works on i386/x86_64) From: Mark Wielaard To: systemtap@sourceware.org Content-Type: text/plain Date: Fri, 17 Apr 2009 14:06:00 -0000 Message-Id: <1239977157.2336.33.camel@fedora.wildebeest.org> Mime-Version: 1.0 Content-Transfer-Encoding: 7bit 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/msg00307.txt.bz2 Hi, I fixed up a couple of small things and enabled the dwarf unwinder for in-kernel unwinding (merge commit 7c2136cf), this also fixes bug #5748 for which there is a testcase in testsuite/systemtap.context/context.exp (backtrace.tcl) that now has all calling functions in the trace (for a specific test module inserted). There can be some improvements to the code. The unwinder sometimes goes on after falling off the stack, when it should really use the fallback stack unwinder that was the default before. But in general the stack traces are more complete than before. There should be more tests written though. Currently the dwarf unwinder is only enabled for i386 and x86_64 in runtime/runtime.h: /* dwarf unwinder only tested so far on i386 and x86_64. */ #if (defined(__i386__) || defined(__x86_64__)) #ifndef STP_USE_DWARF_UNWINDER #define STP_USE_DWARF_UNWINDER #endif #endif This is because the unwinder needs register setup initialization which is currently only defined for i386 and x86_64 in runtime/unwind/[i386| x86_64].h. To support other architectures one needs to add a new header file defining an appropriate struct unwind_frame_info that can be initialized through a function arch_unw_init_frame_info() that takes a struct pt_regs and define a function arch_unw_user_mode() that given a struct unwind_frame_info can detect it reached the end of the kernel stack/start of user space stack (these don't actually work very well in the i386/x86_64 cases btw because the dwarf unwinder cannot currently unwind through the assembly level functions that setup the kernel stack on kernel entry - this is a general issue with unwinding through assembly functions which don't have cfi information that Roland is looking into). Then in the architecture specific runtime/stack-[arch].c file you can use these the enable the dwarf unwinder in your __stp_stack_print() function #ifdef STP_USE_DWARF_UNWINDER and otherwise fallback to some _stp_stack_print_fallback function that does the original heuristic stack walking. At least that is how i386 and x86_64 set things up. I am working on using the dwarf unwinder also for user space backtracing. First using the debug_frame tables that we also are using for the kernel case, but maybe switching to the eh_frame tables (it isn't clear which one is really the most accurate at the moment, we might need to consult both, but I am trying to avoid doing that for now). Cheers, Mark