From: "Ian Munsie" <imunsie@au1.ibm.com>
To: linux-kernel@vger.kernel.org, linuxppc-dev@lists.ozlabs.org
Cc: Masami Hiramatsu <mhiramat@redhat.com>
Subject: perf: Split out arch specific code & improve PowerPC perf probe support
Date: Wed, 14 Apr 2010 15:06:37 +1000 [thread overview]
Message-ID: <1271221600-25533-1-git-send-email-imunsie@au.ibm.com> (raw)
These patches add the required mappings to use perf probe on PowerPC.
Functionality wise it requires the patch titled "powerpc: Add kprobe-based
event tracer" from the powerpc-next tree to provide the
HAVE_REGS_AND_STACK_ACCESS_API required for CONFIG_KPROBE_EVENT. The code will
still compile cleanly without it and will fail gracefully at runtime on the
missing CONFIG_KPROBE_EVENT support as before.
Part 1 of the patch series moves the arch dependent x86 32 and 64 bit DWARF
register number mappings out into a separate arch directory and adds the
necessary Makefile foo to use it.
Part 2 of the patch series adds the PowerPC mappings.
Changes since v1: From Masami Hiramatsu's suggestion, I added a check in the
Makefile for if the arch specific Makefile defines PERF_HAVE_DWARF_REGS,
printing a message during build if it has not. This simplifies the code
removing the odd macro from the previous version and the need for an arch
specific arch_dwarf-regs.h. I have not entirely disabled DWARF support for
architectures that don't implement the register mappings, so that they can
still add a probe based on a line number (they will be missing the ability to
capture the value of a variable from a register).
Thanks,
-Ian
next reply other threads:[~2010-04-14 5:07 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-04-14 5:06 Ian Munsie [this message]
2010-04-14 5:06 ` [PATCH v2 1/2] perf: Move arch specific code into separate arch directory Ian Munsie
2010-04-14 5:06 ` [PATCH v2 2/2] perf probe: Add PowerPC DWARF register number mappings Ian Munsie
2010-04-14 14:46 ` [PATCH v2 1/2] perf: Move arch specific code into separate arch directory Masami Hiramatsu
2010-04-14 17:00 ` Heiko Carstens
2010-04-14 18:49 ` Masami Hiramatsu
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1271221600-25533-1-git-send-email-imunsie@au.ibm.com \
--to=imunsie@au1.ibm.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linuxppc-dev@lists.ozlabs.org \
--cc=mhiramat@redhat.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).