linuxppc-dev.lists.ozlabs.org archive mirror
 help / color / mirror / Atom feed
From: Masami Hiramatsu <mhiramat@redhat.com>
To: Heiko Carstens <heiko.carstens@de.ibm.com>
Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>,
	linux-kernel@vger.kernel.org,
	Arnaldo Carvalho de Melo <acme@redhat.com>,
	Paul Mackerras <paulus@samba.org>,
	Ian Munsie <imunsie@au1.ibm.com>,
	Frederic Weisbecker <fweisbec@gmail.com>,
	Ingo Molnar <mingo@elte.hu>,
	linuxppc-dev@lists.ozlabs.org
Subject: Re: [PATCH v2 1/2] perf: Move arch specific code into separate arch directory
Date: Wed, 14 Apr 2010 11:49:33 -0700	[thread overview]
Message-ID: <4BC60E3D.40200@redhat.com> (raw)
In-Reply-To: <20100414170008.GA2359@osiris.boeblingen.de.ibm.com>

Heiko Carstens wrote:
> On Wed, Apr 14, 2010 at 07:46:12AM -0700, Masami Hiramatsu wrote:
>> Ian Munsie wrote:
>>> From: Ian Munsie <imunsie@au.ibm.com>
>>>
>>> The perf userspace tool included some architecture specific code to map
>>> registers from the DWARF register number into the names used by the regs
>>> and stack access API.
>>>
>>> This patch moves the architecture specific code out into a separate
>>> arch/x86 directory along with the infrastructure required to use it.
>>>
>>> Signed-off-by: Ian Munsie <imunsie@au.ibm.com>
>>> ---
>>> 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).
>>
>> Hmm, sorry, I don't think it is a good way to go... IMHO, porting dwarf-regs.c
>> is so easy (you can just refer systemtap/runtime/loc2c-runtime.h), easier
>> than porting kprobe-tracer on another arch. And perf is a part of kernel tree.
>> It means that someone who are porting kprobe-tracer, he should port
>> dwarf-regs.c too. In that case, PERF_HAVE_DWARF_REGS flag will be used only
>> between those two patches in same patchset. So, I suggested you to drop dwarf
>> support if dwarf-regs mapping doesn't exist.
>>
>> AFAIK, at this point, only s390 users are affected. I'd like to ask
>> them to just port a register mapping on perf and test it too.
> 
> Hm, I'm a bit lost here. Probably due to lack of context. What would be missing
> on s390 and what am I supposed to implement and how can I test it?
> Any pointers to git commits?

Ah, sorry about that. Now we're talking about an idea about porting perf-probe
on some architectures which supports kprobe-tracer.
Ian's patch (https://patchwork.kernel.org/patch/92328/) is currently under
discussion, so there is no git commit yet (but it will be in a few days).

So what I'd like to suggest you is implementing s390 version of DWARF register
mapping support(ppc version is here: https://patchwork.kernel.org/patch/92329/)
for perf probe (a subcommand of perf tools(tools/perf)) and test the perf-probe
can work.

For testing, you may need to compile kernel with CONFIG_DEBUG_INFO, install
elfutils-devel, and make perf tools (cd tools/perf; make).
And then, execute below command.

$ ./perf probe -v --add 'vfs_read file'


Thank you,

-- 
Masami Hiramatsu
e-mail: mhiramat@redhat.com

      reply	other threads:[~2010-04-14 18:46 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-04-14  5:06 perf: Split out arch specific code & improve PowerPC perf probe support Ian Munsie
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 [this message]

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=4BC60E3D.40200@redhat.com \
    --to=mhiramat@redhat.com \
    --cc=a.p.zijlstra@chello.nl \
    --cc=acme@redhat.com \
    --cc=fweisbec@gmail.com \
    --cc=heiko.carstens@de.ibm.com \
    --cc=imunsie@au1.ibm.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linuxppc-dev@lists.ozlabs.org \
    --cc=mingo@elte.hu \
    --cc=paulus@samba.org \
    /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).