From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 1929 invoked by alias); 21 May 2009 22:57:29 -0000 Received: (qmail 1921 invoked by uid 22791); 21 May 2009 22:57:28 -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 22:57:23 +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 n4LMvLhk022908 for ; Thu, 21 May 2009 18:57:21 -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 n4LMvKbU022405; Thu, 21 May 2009 18:57:21 -0400 Received: from [10.32.10.110] (vpn-10-110.str.redhat.com [10.32.10.110]) by ns3.rdu.redhat.com (8.13.8/8.13.8) with ESMTP id n4LMvJAC025345; Thu, 21 May 2009 18:57:19 -0400 Subject: Re: dwarf unwinder (only works on i386/x86_64) - now with eh_frame and debug_frame fallback From: Mark Wielaard To: Roland McGrath Cc: systemtap@sourceware.org In-Reply-To: <20090521184400.1A58EFC38D@magilla.sf.frob.com> References: <1239977157.2336.33.camel@fedora.wildebeest.org> <1240347505.19523.41.camel@hermans.wildebeest.org> <1242893011.3655.47.camel@hermans.wildebeest.org> <20090521184400.1A58EFC38D@magilla.sf.frob.com> Content-Type: text/plain Date: Thu, 21 May 2009 22:57:00 -0000 Message-Id: <1242946638.3655.55.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/msg00664.txt.bz2 On Thu, 2009-05-21 at 11:44 -0700, Roland McGrath wrote: > > 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. > > In the long run I think the right thing here will be to convert the data at > translation time. That is, make all addresses use a simple "absolute" form > (as is usual in .debug_frame), which really means "loadbase-relative" for > DSOs--i.e., the same as addresses in the symbol table, etc. Then at run > time you just have one uniform way to treat addresses in each module. > That keeps things as simple as possible at runtime. Yes, agreed. > > Some optimizations that could be done: > > - Use the eh_frame_hdr binary search table > > (needs careful auditing of adjustStartAddress -> read_pointer). > [...] > > - Merge debug_frame and eh_frame at runtime and build our own > > binary search hdr. > > By "runtime" here, you mean "translation time", right? In the unspecified > future, elfutils libs will provide easy-to-use code for merging tables, > emitting them in whichever format, and generating binary search tables. > Probably any such optimization concerns can wait for that. Yes, I meant translation time. It would be wonderful if elfutils provides an easy way to, merge the tables, transform them to be "loadbase-relative" and generate a binary-search hdr for the result. I am not sure how urgent such an cleanup and optimization is, we don't have much experience with the user backtraces (or the kernel dwarf unwinder for that matter). It isn't on my "short-list" at the moment. Cheers, Mark