[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20120725170530.GE1173@somewhere.redhat.com>
Date: Wed, 25 Jul 2012 19:05:33 +0200
From: Frederic Weisbecker <fweisbec@...il.com>
To: Jiri Olsa <jolsa@...hat.com>
Cc: acme@...hat.com, a.p.zijlstra@...llo.nl, mingo@...e.hu,
paulus@...ba.org, cjashfor@...ux.vnet.ibm.com, eranian@...gle.com,
gorcunov@...nvz.org, tzanussi@...il.com, mhiramat@...hat.com,
robert.richter@....com, fche@...hat.com,
linux-kernel@...r.kernel.org, masami.hiramatsu.pt@...achi.com,
drepper@...il.com, asharma@...com, benjamin.redelings@...cent.org
Subject: Re: [PATCH 14/17] perf, tool: Support for dwarf cfi unwinding on
post processing
On Sun, Jul 22, 2012 at 02:14:37PM +0200, Jiri Olsa wrote:
> This brings the support for dwarf cfi unwinding on perf post
> processing. Call frame informations are retrieved and then passed
> to libunwind that requests memory and register content from the
> applications.
>
> Adding unwind object to handle the user stack backtrace based
> on the user register values and user stack dump.
>
> The unwind object access the libunwind via remote interface
> and provides to it all the necessary data to unwind the stack.
>
> The unwind interface provides following function:
> unwind__get_entries
>
> And callback (specified in above function) to retrieve
> the backtrace entries:
> typedef int (*unwind_entry_cb_t)(struct unwind_entry *entry,
> void *arg);
>
> Signed-off-by: Jiri Olsa <jolsa@...hat.com>
> Signed-off-by: Frederic Weisbecker <fweisbec@...il.com>
> ---
> tools/perf/Makefile | 2 +
> tools/perf/arch/x86/Makefile | 3 +
> tools/perf/arch/x86/util/unwind.c | 111 ++++
> tools/perf/builtin-report.c | 24 +-
> tools/perf/builtin-script.c | 16 +-
> tools/perf/builtin-top.c | 5 +-
> tools/perf/util/include/linux/compiler.h | 1 +
> tools/perf/util/map.h | 7 +-
> .../perf/util/scripting-engines/trace-event-perl.c | 3 +-
> .../util/scripting-engines/trace-event-python.c | 3 +-
> tools/perf/util/session.c | 61 ++-
> tools/perf/util/session.h | 3 +-
> tools/perf/util/trace-event-scripting.c | 3 +-
> tools/perf/util/trace-event.h | 5 +-
> tools/perf/util/unwind.c | 567 ++++++++++++++++++++
> tools/perf/util/unwind.h | 34 ++
> 16 files changed, 811 insertions(+), 37 deletions(-)
> create mode 100644 tools/perf/arch/x86/util/unwind.c
> create mode 100644 tools/perf/util/unwind.c
> create mode 100644 tools/perf/util/unwind.h
>
> diff --git a/tools/perf/Makefile b/tools/perf/Makefile
> index d0c3291..c18c790 100644
> --- a/tools/perf/Makefile
> +++ b/tools/perf/Makefile
> @@ -328,6 +328,7 @@ LIB_H += util/cgroup.h
> LIB_H += $(TRACE_EVENT_DIR)event-parse.h
> LIB_H += util/target.h
> LIB_H += util/perf_regs.h
> +LIB_H += util/unwind.h
>
> LIB_OBJS += $(OUTPUT)util/abspath.o
> LIB_OBJS += $(OUTPUT)util/alias.o
> @@ -513,6 +514,7 @@ else
> EXTLIBS += $(LIBUNWIND_LIBS)
> BASIC_CFLAGS := $(LIBUNWIND_CFLAGS) $(BASIC_CFLAGS)
> BASIC_LDFLAGS := $(LIBUNWIND_LDFLAGS) $(BASIC_LDFLAGS)
> + LIB_OBJS += $(OUTPUT)util/unwind.o
> endif
>
> ifdef NO_NEWT
> diff --git a/tools/perf/arch/x86/Makefile b/tools/perf/arch/x86/Makefile
> index 744e629..815841c 100644
> --- a/tools/perf/arch/x86/Makefile
> +++ b/tools/perf/arch/x86/Makefile
> @@ -2,4 +2,7 @@ ifndef NO_DWARF
> PERF_HAVE_DWARF_REGS := 1
> LIB_OBJS += $(OUTPUT)arch/$(ARCH)/util/dwarf-regs.o
> endif
> +ifndef NO_LIBUNWIND
> +LIB_OBJS += $(OUTPUT)arch/$(ARCH)/util/unwind.o
> +endif
> LIB_OBJS += $(OUTPUT)arch/$(ARCH)/util/header.o
> diff --git a/tools/perf/arch/x86/util/unwind.c b/tools/perf/arch/x86/util/unwind.c
> new file mode 100644
> index 0000000..78d956e
> --- /dev/null
> +++ b/tools/perf/arch/x86/util/unwind.c
> @@ -0,0 +1,111 @@
> +
> +#include <errno.h>
> +#include <libunwind.h>
> +#include "perf_regs.h"
> +#include "../../util/unwind.h"
> +
> +#ifdef ARCH_X86_64
> +int unwind__arch_reg_id(int regnum)
Please try to avoid __ in function names. We used that convention
before but we gave up because that's actually more painful than
anything.
--
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