From: Wang YanQing <udknight@gmail.com>
To: Jiri Olsa <jolsa@redhat.com>
Cc: acme@kernel.org, peterz@infradead.org, mingo@redhat.com,
alexander.shishkin@linux.intel.com, linux-kernel@vger.kernel.org
Subject: Re: [PATCH] perf report: Provide libtraceevent with a kernel symbol resolver
Date: Wed, 17 Jan 2018 00:48:12 +0800 [thread overview]
Message-ID: <20180116164812.GA4118@udknight> (raw)
In-Reply-To: <20180115100611.GB14646@krava>
On Mon, Jan 15, 2018 at 11:06:11AM +0100, Jiri Olsa wrote:
> On Mon, Jan 15, 2018 at 12:47:32PM +0800, Wang YanQing wrote:
> > So that beautifiers wanting to resolve kernel function addresses to
> > names can do its work, and when we use "perf report" for output of
> > "perf kmem record", we will get kernel symbol output.
> >
> > Signed-off-by: Wang YanQing <udknight@gmail.com>
> > ---
> > tools/perf/builtin-report.c | 9 +++++++++
> > 1 file changed, 9 insertions(+)
> >
> > diff --git a/tools/perf/builtin-report.c b/tools/perf/builtin-report.c
> > index dd4df9a..7b65100 100644
> > --- a/tools/perf/builtin-report.c
> > +++ b/tools/perf/builtin-report.c
> > @@ -1317,6 +1317,15 @@ int cmd_report(int argc, const char **argv)
> > report.range_num = 1;
> > }
> >
> > + if (session->tevent.pevent &&
> > + pevent_set_function_resolver(session->tevent.pevent,
> > + machine__resolve_kernel_addr,
> > + &session->machines.host) < 0) {
> > + pr_err("%s: failed to set libtraceevent function resolver\n",
> > + __func__);
> > + return -1;
> > + }
>
> why not calling the wrapper trace_event__register_resolver?
The reason is the same as builtin-script doesn't use trace_event__register_resolver,
because we only use report and script to analyze offline perf.data, and there could
be no tracepoints in perf.data.
The wrapper trace_event__register_resolver always initialize tevent.pevent, and calling
pevent_set_function_resolver which isn't necessary when there is no tracepoints in the
perf.data.
>
> jirka
>
> > +
> > sort__setup_elide(stdout);
> >
> > ret = __cmd_report(&report);
> > --
> > 1.8.5.6.2.g3d8a54e.dirty
> >
next prev parent reply other threads:[~2018-01-16 17:02 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-01-15 4:47 [PATCH] perf report: Provide libtraceevent with a kernel symbol resolver Wang YanQing
2018-01-15 10:06 ` Jiri Olsa
2018-01-16 16:48 ` Wang YanQing [this message]
2018-01-18 9:43 ` Jiri Olsa
2018-01-18 14:22 ` Wang YanQing
2018-01-19 18:57 ` Jiri Olsa
2018-01-21 17:25 ` Wang YanQing
2018-01-23 12:41 ` Jiri Olsa
2018-02-08 12:20 ` Jiri Olsa
2018-03-06 7:36 ` Wang YanQing
2018-03-06 14:01 ` Arnaldo Carvalho de Melo
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20180116164812.GA4118@udknight \
--to=udknight@gmail.com \
--cc=acme@kernel.org \
--cc=alexander.shishkin@linux.intel.com \
--cc=jolsa@redhat.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@redhat.com \
--cc=peterz@infradead.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.