linux-kernel - Re: Perf record format portability

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] [thread-next>] [day] [month] [year] [list]

Date:	Thu, 17 May 2012 07:48:46 -0400
From:	Steven Rostedt <rostedt@...dmis.org>
To:	Dmitry Antipov <dmitry.antipov@...aro.org>
Cc:	Arnaldo Carvalho de Melo <acme@...stprotocols.net>,
	Peter Zijlstra <a.p.zijlstra@...llo.nl>,
	Paul Mackerras <paulus@...ba.org>,
	Ingo Molnar <mingo@...hat.com>,
	Amit Kucheria <amit.kucheria@...aro.org>,
	linaro-dev@...ts.linaro.org, linux-kernel@...r.kernel.org,
	Jiri Olsa <jolsa@...hat.com>
Subject: Re: Perf record format portability

On Thu, 2012-05-17 at 09:10 +0400, Dmitry Antipov wrote:
> On 05/16/2012 08:58 PM, Steven Rostedt wrote:
> 
> > On Wed, 2012-05-16 at 11:59 -0300, Arnaldo Carvalho de Melo wrote:
> >
> >> Steve,
> >>
> >> 	Was the kernel trace events infrastructure designed with that in
> >> mind? I.e. cross analysis? I must be missing something here, still
> >> ENOCOFFEE :-\
> >
> > Yes, the libparsevents library was design for this from day one. That's
> > why trace-cmd data file can be run on an ARM and read on x86, or PPC, or
> > whatever. I did all my development testing against 32bit, 64bit and big
> > and little endian. This was the case from the beginning.
> 
> I didn't face with big/little conversion issues, most probably both x86 and
> my ARM board are of the same (little) endian :-).
> 
> But the original question was about event IDs. For example,
> /sys/kernel/debug/tracing/events/sched/sched_switch/id is 55 on my ARM board
> and 279 on my PC host, so 'perf report' displays "unknown:unknown" instead
> of expected "sched:sched_switch" when attempting to do some cross-analysis.
> I suppose that original event IDs should be preserved, either within perf.data
> or by providing the copy of original /sys/kernel/debug/tracing/*, much like
> it's done with --kallsyms to resolve kernel symbols.

trace-cmd copies the entire /sys/kernel/debug/tracing/events directory
into the data file (well it copies only the events you specify). I
thought perf did the same. It should be using what's in the perf.dat
file and not what's on the host.

Again, perf report is not what uses the events from trace-cmd. It's perf
script that does. If perf script works, then perf report needs to be
fixed. But after it gets updated to use the latest libparse-events,
which I have no idea when that will ever happen.

-- Steve

--
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/