From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 22938 invoked by alias); 21 May 2009 08:03:47 -0000 Received: (qmail 22797 invoked by uid 22791); 21 May 2009 08:03:46 -0000 X-SWARE-Spam-Status: No, hits=-2.2 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; Thu, 21 May 2009 08:03:36 +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 n4L83Ydw025353 for ; Thu, 21 May 2009 04:03:34 -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 n4L83Yp1024648 for ; Thu, 21 May 2009 04:03:34 -0400 Received: from [10.32.10.9] (vpn-10-9.str.redhat.com [10.32.10.9]) by ns3.rdu.redhat.com (8.13.8/8.13.8) with ESMTP id n4L83Wqi022310 for ; Thu, 21 May 2009 04:03:33 -0400 Subject: Re: dwarf unwinder (only works on i386/x86_64) - now with eh_frame and debug_frame fallback From: Mark Wielaard To: systemtap@sourceware.org In-Reply-To: <1240347505.19523.41.camel@hermans.wildebeest.org> References: <1239977157.2336.33.camel@fedora.wildebeest.org> <1240347505.19523.41.camel@hermans.wildebeest.org> Content-Type: text/plain Date: Thu, 21 May 2009 08:03:00 -0000 Message-Id: <1242893011.3655.47.camel@hermans.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/msg00655.txt.bz2 Hi, Yesterday I pushed some commits to make the dwarf unwinder use both debug_frame and eh_frame tables. At first I had wanted to just used debug_frame tables for the kernel and eh_frame for user space, but depending on the gcc version, architecture (and apparently GNU/Linux distro defaults), either table can be missing or only have partial coverage (see gcc options -fexceptions, -fnon-call-exceptions, -funwind-tables and -fasynchronous-unwind-tables). So currently we default to the debug_frame table, and if that fails to unwind for a particular location we fall back and retry using the eh_frame table. This make the uprobes_ustack.exp testcase (and hopefully user stack traces in general) work against gcc 4.4 (which is the default compiler for fedora 11). Please do test and let me know of any situations where things don't seem to work (especially if the uprobes_ustack.exp testcase fails). Currently the dwarf unwinder is only enabled on i386 and x86_64. It would be interesting to see if it can easily be enabled on other architectures. The "ugly" code in these patches is in adjustStartAddress() in runtime/unwind.c. This really should go into _stp_module_relocate or read_pointer. One tricky issue here is that we read the eh_frame section during translation time and then load it in kernel space at module init time. eh_frame tables can use pointer encodings that are absolute or pc_relative (actually data relative), so we need to readjust for the new load location of the eh_frame. Some optimizations that could be done: - Use the eh_frame_hdr binary search table (needs careful auditing of adjustStartAddress -> read_pointer). - Try to read eh_frame in-place from user space (risks tricky page fault issues if not available) - Merge debug_frame and eh_frame at runtime and build our own binary search hdr. But for now I won't be working on those, unless the backtraces become a bottleneck for actual code using them. Next steps to make stacktraces better are: - Add more tests (in particular ones that test prelinking and missing or split-file debuginfo). - Make vma-tracker more robust (_stp_tf_mmap_cb) Wenji send me some notes on things it seems to miss. If we cannot track a location to a _stp_module we cannot unwind. - Track vdso for process symbols/backtraces. PR10080. - Simplify unwind interface. Architecture dependent code has too much duplication. Need to just handle address, not function symbol printing. - Nicer fallback to in-kernel unwinder/backtrace, in particular for backtracing from non-pt_regs probe context. PR6961. - unwind through kretprobes. PR6436/PR9999. - Better tapset functions for handling stacks. PR6580. I'll be away for a couple of days, but will be back early next week. Cheers, Mark