From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 15080 invoked by alias); 5 Aug 2013 08:46:47 -0000 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 Received: (qmail 15068 invoked by uid 89); 5 Aug 2013 08:46:47 -0000 X-Spam-SWARE-Status: No, score=-1.2 required=5.0 tests=AWL,BAYES_00,KHOP_THREADED,RDNS_NONE,SPF_PASS autolearn=no version=3.3.1 Received: from Unknown (HELO mail-de.keymile.com) (195.8.104.250) by sourceware.org (qpsmtpd/0.84/v0.84-167-ge50287c) with ESMTP; Mon, 05 Aug 2013 08:46:45 +0000 Received: from frodo.de.keymile.net ([10.9.1.54]:34224 helo=mailrelay.de.keymile.net) by mail-de.keymile.com with esmtp (Exim 4.76) (envelope-from ) id 1V6GQz-00033Z-2d; Mon, 05 Aug 2013 10:46:33 +0200 Received: from srvdehan1003.de.keymile.net (srvdehan1003.de.keymile.net [10.9.1.108]) by mailrelay.de.keymile.net (8.12.2/8.12.2) with ESMTP id r758iKnV002972; Mon, 5 Aug 2013 10:44:21 +0200 (MEST) Received: from pc005093.de.keymile.net.de.keymile.net ([172.30.2.67]) by srvdehan1003.de.keymile.net with Microsoft SMTPSVC(6.0.3790.3959); Mon, 5 Aug 2013 10:46:31 +0200 Message-ID: <51FF6667.1090404@keymile.com> Date: Mon, 05 Aug 2013 08:46:00 -0000 From: Holger Brunck User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130625 Thunderbird/17.0.7 MIME-Version: 1.0 To: Lukas Berk CC: Mark Wielaard , systemtap@sourceware.org Subject: Re: print_ubacktrace() and ppc 32 References: <51BF1C1E.7020208@keymile.com> <1371491014.4501.97.camel@bordewijk.wildebeest.org> <20130617180008.GC2219@redhat.com> <1371492348.4501.106.camel@bordewijk.wildebeest.org> <51C005AA.8010300@keymile.com> <20130803011202.GA1956@redhat.com> In-Reply-To: <20130803011202.GA1956@redhat.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-SW-Source: 2013-q3/txt/msg00099.txt.bz2 Hi, On 08/03/2013 03:12 AM, Lukas Berk wrote: >>> So for a ppc32 kernel we do need a new runtime/unwind/ppc32.h >>> definitions file. It should not be that hard to write based on the >>> ppc64.h version and the ppc32 DWARF register mappings from >>> http://refspecs.linuxbase.org/elf/elfspec_ppc.pdf >>> But note that testing might be needed to see if those really map to >>> actually used DWARF register numbers generated by the toolchain. As can >>> be seen in the comments in ppc64.h sometimes mistakes have been made and >>> theory/spec and practice are not the same :{ >> >> Ok thanks for pointing out. If someone has a first ppc32.h file and needs >> some help for testing on a native 32 bit ppc system, let me know. Or maybe >> in the next week I find the time to implement one. > > Looking over the DWARF register specs the mappings should be the same, > so hopefully we can use the same header file. Would you mind trying > this patch? > no unfortunately it does not work. First I had to fix a compile error because "softe" is not defined for ppc_32 in the linux kernel in ptrace.h. I changed it temporary to "mq" in runtime/unwind/ppc_64.h and then I was able to compile my probe. I gave it a try with a simple main.c which calls a function foo(). My probe was: probe process("/usr/local/bin/main").function("foo") { print_ubacktrace() } But the output is: 0x10000448 : foo+0x1c/0x7c [/usr/local/bin/main] So the calling function main() was not shown on an ARM architecture a similar setup shows: 0x83b8 : foo+0x14/0x64 [/usr/local/bin/main] 0x8444 : main+0x3c/0x40 [/usr/local/bin/main] So there is still something missing for ppc32. Best regards Holger