linux-kernel - Re: [PATCH v2 1/2] perf: Move arch specific code into separate arch directory

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <4BC60E3D.40200@redhat.com>
Date:	Wed, 14 Apr 2010 11:49:33 -0700
From:	Masami Hiramatsu <mhiramat@...hat.com>
To:	Heiko Carstens <heiko.carstens@...ibm.com>
CC:	Ian Munsie <imunsie@....ibm.com>, linux-kernel@...r.kernel.org,
	linuxppc-dev@...ts.ozlabs.org, benh@...nel.crashing.org,
	Peter Zijlstra <a.p.zijlstra@...llo.nl>,
	Paul Mackerras <paulus@...ba.org>, Ingo Molnar <mingo@...e.hu>,
	Arnaldo Carvalho de Melo <acme@...hat.com>,
	Frederic Weisbecker <fweisbec@...il.com>
Subject: Re: [PATCH v2 1/2] perf: Move arch specific code into separate arch
 directory

Heiko Carstens wrote:
> On Wed, Apr 14, 2010 at 07:46:12AM -0700, Masami Hiramatsu wrote:
>> Ian Munsie wrote:
>>> From: Ian Munsie <imunsie@...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@...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@...hat.com

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/