From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 7148 invoked by alias); 7 Oct 2011 11:22:14 -0000 Received: (qmail 7139 invoked by uid 22791); 7 Oct 2011 11:22:13 -0000 X-SWARE-Spam-Status: No, hits=-6.7 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_HI,RP_MATCHES_RCVD,SPF_HELO_PASS X-Spam-Check-By: sourceware.org Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Fri, 07 Oct 2011 11:21:57 +0000 Received: from int-mx09.intmail.prod.int.phx2.redhat.com (int-mx09.intmail.prod.int.phx2.redhat.com [10.5.11.22]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id p97BLv8A020465 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Fri, 7 Oct 2011 07:21:57 -0400 Received: from springer.wildebeest.org (ovpn-116-38.ams2.redhat.com [10.36.116.38]) by int-mx09.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id p97BLtjj019843 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Fri, 7 Oct 2011 07:21:57 -0400 Received: by springer.wildebeest.org (Postfix, from userid 500) id 2D11E46638; Fri, 7 Oct 2011 13:21:55 +0200 (CEST) Subject: Enabling dwarf unwinder for ppc64 From: Mark Wielaard To: systemtap@sourceware.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Date: Fri, 07 Oct 2011 11:22:00 -0000 Message-ID: <1317986514.3351.26.camel@springer.wildebeest.org> Mime-Version: 1.0 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: 2011-q4/txt/msg00019.txt.bz2 Hi, After a couple of fixes and cleanups to the generic unwinder code I have finally enabled the dwarf unwinder for ppc64. The final commit (d4bcac) was actually pretty small. So hopefully this means enabling it for other arches should not be too much work. In particular it is probably very close to also work for ppc[32], but I didn't have such a setup. I have only tested in on a 2.6.32 ppc64 kernel with gcc 4.4.6. If people have other setups and could test it there that would be highly appreciated. Also it would be good if someone who actually knows powerpc took a look at runtime/unwind/ppc64.h to double check it looks somewhat sane. The debug frame register numbering is somewhat strange (instead of using dwarf register numbers, it is using gcc internal register numbering...). I added a comment with a pointer to some discussion about the confusion this causes. We only track the general integer registers, mq, link and count. But no floating point, vector, or flag registers. This is mostly what is available through pt_regs inside the kernel anyway. It seems this is all we need for kernel unwinding, and I hope it is enough for user space too, but I haven't studied user space ppc unwind tables too much yet. It isn't perfect yet, but good enough to make all context.exp kernel/cross-module backtrace tests work. For kernel unwinding it seems good. For user space unwinding there are a couple of issues. Specifically symbol lookup seems broken. We discussed this some time ago on this list and this is what I am going to look into next, because that obscures all other issues (32-on-64 doesn't work and vma-vdso tests failing). Cheers, Mark