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]
Date:	Wed, 13 Oct 2010 07:06:52 +0200
From:	Frederic Weisbecker <fweisbec@...il.com>
To:	LKML <linux-kernel@...r.kernel.org>
Cc:	LKML <linux-kernel@...r.kernel.org>,
	Frederic Weisbecker <fweisbec@...il.com>,
	Peter Zijlstra <a.p.zijlstra@...llo.nl>,
	Arnaldo Carvalho de Melo <acme@...hat.com>,
	Paul Mackerras <paulus@...ba.org>,
	Stephane Eranian <eranian@...gle.com>,
	Cyrill Gorcunov <gorcunov@...nvz.org>,
	Tom Zanussi <tzanussi@...il.com>,
	Masami Hiramatsu <mhiramat@...hat.com>,
	Steven Rostedt <rostedt@...dmis.org>,
	Robert Richter <robert.richter@....com>
Subject: [RFC] perf: Dwarf cfi based user callchains

Hi,

This brings dwarf cfi based callchain for userspace apps that don't have
frame pointers.

To test it, you can try:

perf record -g dwarf,24000 -e cycles:u ./hackbench 2
perf report

It seems to work but there are of course many things to improve:

- do only userspace profiling with that mode for now (the :u flag as above).
  The reason is that if you profile also the kernel, the user callchains
  will often start from vdso if the user made a syscall, and vdso doesn't
  have cfi informations, so we get stuck there. I need to find a solution for
  that, like doing a single frame pointer deref on the first entry (vdso)
  and continue with dwarves, but I need to know if we came from a syscall for
  that. Not sure yet how I'll handle that.

- it only works with .eh_frame, I think there is an elf section that is made
  almost the same but with few differences. I don't remember the name at that
  time but that needs a look.

- it's slow. A first improvement to make it faster is to support binary
  search from .eh_frame_hdr. This will probably be one of the next things
  I'll focus in. And the whole needs perhaps more caching and so on.

- only support for x86-32. I need to split some arch specific code from
  generic and add at least x86-64 support.

- there are still some callchains that are not unwind. I need to investigate.

This can be found in:

git://git.kernel.org/pub/scm/linux/kernel/git/frederic/random-tracing.git
	perf/unwind-v1

Thanks,
	Frederic
---

Frederic Weisbecker (9):
      uaccess: Make copy_from_user_nmi() globally available
      perf: Add ability to dump user regs
      perf: Add ability to dump part of the user stack
      perf: Don't record frame pointer based user stacktraces if we dump stack and regs
      perf: Support for dwarf mode callchain on perf record
      perf: Build with dwarf cfi
      perf: Support for error passed over pointers
      perf: Add libunwind dependency for dwarf cfi unwinding
      perf: Support for dwarf cfi unwinding on post processing


 arch/x86/include/asm/uaccess.h      |    5 +
 arch/x86/kernel/cpu/perf_event.c    |    4 +-
 include/asm-generic/uaccess.h       |    4 +
 include/linux/perf_event.h          |   15 +-
 kernel/perf_event.c                 |  182 +++++-
 tools/perf/Makefile                 |   23 +-
 tools/perf/builtin-record.c         |   76 +++-
 tools/perf/builtin-report.c         |    9 +-
 tools/perf/feature-tests.mak        |   14 +
 tools/perf/perf.h                   |    5 +
 tools/perf/util/callchain.c         |   35 +-
 tools/perf/util/callchain.h         |   19 +-
 tools/perf/util/event.c             |   29 +
 tools/perf/util/event.h             |    7 +
 tools/perf/util/include/linux/err.h |   24 +
 tools/perf/util/unwind.c            | 1077 +++++++++++++++++++++++++++++++++++
 16 files changed, 1485 insertions(+), 43 deletions(-)
--
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/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ