linux-kernel - Analysing an ARM perf.data file on a x86-64 workstation

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

Message-ID: <20100119130958.GG14636@ghostprotocols.net>
Date:	Tue, 19 Jan 2010 11:09:58 -0200
From:	Arnaldo Carvalho de Melo <acme@...radead.org>
To:	Jamie Iles <jamie.iles@...ochip.com>
Cc:	linux-perf-users@...r.kernel.org,
	Frédéric Weisbecker <fweisbec@...il.com>,
	Mike Galbraith <efault@....de>,
	Peter Zijlstra <a.p.zijlstra@...llo.nl>,
	Paul Mackerras <paulus@...ba.org>, Ingo Molnar <mingo@...e.hu>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Analysing an ARM perf.data file on a x86-64 workstation

CCing linux-perf-users, this may be interesting when investigating
similar problems for other arches.

Thanks James, got the vmlinux file and and already found and fixed two
bugs, patches sent CCed to you.

Ok, now how does it look like?

[acme@...pio linux-2.6-tip]$ perf report -i ~/iles/perf.data --vmlinux ~/iles/vmlinux 
Failed to open /lib/ld-2.8.so, continuing without symbols
Failed to open /root/perf, continuing without symbols
Failed to open /lib/libc-2.8.so, continuing without symbols
# Samples: 40653353521
#
# Overhead          Command      Shared Object  Symbol
# ........  ...............  .................  ......
#
    99.94%          swapper           c0020ac4  [k] 0x000000c0020ac4
     0.04%             perf           c0068f48  [k] 0x000000c0068f48
     0.01%             perf  libc-2.8.so        [.] 0x00000000067198
     0.01%            sleep           c00acb44  [k] 0x000000c00acb44
     0.00%             perf  perf               [.] 0x0000000000265c
     0.00%             perf  ld-2.8.so          [.] 0x00000000015fa8
     0.00%            sleep  ld-2.8.so          [.] 0x00000000008ff0
     0.00%             perf  [kernel.kallsyms]  [k] smp_call_function_single
#
# (For a higher level overview, try: perf report --sort comm,dso)
#
[acme@...pio linux-2.6-tip]$

So we manage to decode at least one kernel entry, yay!

To make sure we really did it right, we can use -v to show the address
too:

[acme@...pio linux-2.6-tip]$ perf report -v -i ~/iles/perf.data --vmlinux ~/iles/vmlinux 
Failed to open /lib/ld-2.8.so, continuing without symbols
Failed to open /root/perf, continuing without symbols
Failed to open /lib/libc-2.8.so, continuing without symbols
# Samples: 40653353521
#
# Overhead          Command      Shared Object  Symbol
# ........  ...............  .................  ......
#
    99.94%          swapper           c0020ac4  0x00000000c0020ac4 ! [k] 0x000000c0020ac4
     0.04%             perf           c0068f48  0x00000000c0068f48 ! [k] 0x000000c0068f48
     0.01%             perf  /lib/libc-2.8.so   0x0000000000067198 K [.] 0x00000000067198
     0.01%            sleep           c00acb44  0x00000000c00acb44 ! [k] 0x000000c00acb44
     0.00%             perf  /root/perf         0x000000000000265c K [.] 0x0000000000265c
     0.00%             perf  /lib/ld-2.8.so     0x0000000000015fa8 K [.] 0x00000000015fa8
     0.00%            sleep  /lib/ld-2.8.so     0x0000000000008ff0 K [.] 0x00000000008ff0
     0.00%             perf  [kernel.kallsyms]  0x00000000c0068f48 ! [k] smp_call_function_single
#
# (For a higher level overview, try: perf report --sort comm,dso)
#
[acme@...pio linux-2.6-tip]$

Ok, so smp_call_function_single is 0xc0068f48, lets see if that matches
what is in the vmlinux symtab you provided me:

[acme@...pio linux-2.6-tip]$ file ~/iles/vmlinux 
/home/acme/iles/vmlinux: ELF 32-bit LSB executable, ARM, version 1 (SYSV), statically linked, not stripped
[acme@...pio linux-2.6-tip]$ readelf -s ~/iles/vmlinux | grep smp_call_function_single
 57421: c0068f18    60 FUNC    GLOBAL DEFAULT    3 smp_call_function_single
[acme@...pio linux-2.6-tip]$

Ok, it matches, as 0xc0068f18 <= 0xc0068f48 < (0xc0068f18 + 0x60).

But what about the other addresses for [k]ernel space perf hits such as
0xc0020ac4, 0xc0068f48, etc?

0xc0020ac4 is around here:

   385: 00000000     0 FILE    LOCAL  DEFAULT  ABS process.c
<SNIP>
   411: c0020aa0    40 FUNC    LOCAL  DEFAULT    3 default_idle
   412: c0020ac8     0 NOTYPE  LOCAL  DEFAULT    3 $a

so its well possible that this is really a very idle machine, right?

0xc0068f48 is around here:

  7997: 00000000     0 FILE    LOCAL  DEFAULT  ABS up.c
  7998: c0068f18     0 NOTYPE  LOCAL  DEFAULT    3 $a
  7999: c0068f50     0 NOTYPE  LOCAL  DEFAULT    3 $d

0xc00acb44 around here:

 13645: 00000000     0 FILE    LOCAL  DEFAULT  ABS mmap.c
<SNIP>
 13679: c00aca98   216 FUNC    LOCAL  DEFAULT    3 __vma_link_file
 13680: c00acb70     0 NOTYPE  LOCAL  DEFAULT    3 $a
 13681: c00acb70   428 FUNC    LOCAL  DEFAULT    3 unmap_region

We now need to try to investigate why these things are being
misannotated in the symtab.

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