From: Stephane Eranian on
On Wed, May 26, 2010 at 9:32 PM, Arnaldo Carvalho de Melo
<acme(a)infradead.org> wrote:
> Em Wed, May 26, 2010 at 09:07:05PM +0200, Stephane Eranian escreveu:
>> Hi,
>>
>> +lkml et al.
>>
>> On Wed, May 26, 2010 at 8:23 PM, Arnaldo Carvalho de Melo
>> <acme(a)infradead.org> wrote:
>> > Em Wed, May 26, 2010 at 06:45:18PM +0200, Stephane Eranian escreveu:
>> >> Attached is the trace for
>> >> perf annotate -i ~/perf.data noploop
>> >>
>> >> I get no output at all (TUI is off). Copied over .debug tarball + perf.data.
>> >
>> > Looks like the bug I'm investigating now:
>> >
>> > build id event received for [kernel.kallsyms]: 54b1e7cc3cf52e0db255aab44ce7538eb62655b8
>> > build id event received for /tmp/noploop: 875ae61623e89f408b425ca0486a9ec99e3ac73e
>> > Looking at the vmlinux_path (5 entries long)
>> > No build_id in vmlinux, ignoring it
>> > No build_id in /boot/vmlinux, ignoring it
>> > No build_id in /boot/vmlinux-2.6.34-tip-default+, ignoring it
>> > build_id in /lib/modules/2.6.34-tip-default+/build/vmlinux is
>> > 3635a0e8dfc9a1afbd5627c2ba789e41d77d3cd1 while expected is
>> > 54b1e7cc3cf52e0db255aab44ce7538eb62655b8, ignoring it
>> > No build_id in /usr/lib/debug/lib/modules/2.6.34-tip-default+/vmlinux, ignoring it
>> >
>> > In my case it is not finding the vmlinux because I'm using RHEL6 Beta
>> > kernel without the respective kernel-debuginfo{-common} packages so it
>> > doesn't find the vmlinux, uses just /proc/kallsyms and that is not
>> > enough for annotation.
>> >
>> > In your case the problem is that we only cache the kallsyms file in the
>> > build-id cache ($HOME/.debug) and that is not enough for annotation, so
>> > I have to fix two things:
>> >
>> I can understand the issue with the kernel symbols.
>
> That has to be fixed and I've got some patches already for that, testing
> them now.
>
>> But in this example, I only really care about the symbols in the
>> noploop program (/tmp/noploop).
>>
>> Missing symbol support for the kernel should not cause perf to avoid
>> trying to resolve the symbols in other modules such as my user program
>> here.
>
> Right, my bad, I thought that the problem was about the kernel symbols.
>
> Then can you try replacing:
>
> perf annotate -i ~/perf.data noploop
>
> with:
>
> perf annotate -i ~/perf.data -d noploop
>
> And see if that helps?
>
Ok that works. But if I turned on TUI, then I cannot obtain
the same result. I am guessing it does not use the -d option.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo(a)vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
From: Arnaldo Carvalho de Melo on
Em Wed, May 26, 2010 at 10:11:14PM +0200, Stephane Eranian escreveu:
> On Wed, May 26, 2010 at 9:32 PM, Arnaldo Carvalho de Melo
> <acme(a)infradead.org> wrote:
> > Em Wed, May 26, 2010 at 09:07:05PM +0200, Stephane Eranian escreveu:
> >> But in this example, I only really care about the symbols in the
> >> noploop program (/tmp/noploop).
> >>
> >> Missing symbol support for the kernel should not cause perf to avoid
> >> trying to resolve the symbols in other modules such as my user program
> >> here.
> >
> > Right, my bad, I thought that the problem was about the kernel symbols.
> >
> > Then can you try replacing:
> >
> > perf annotate -i ~/perf.data noploop
> >
> > with:
> >
> > perf annotate -i ~/perf.data -d noploop
> >
> > And see if that helps?
> >
> Ok that works. But if I turned on TUI, then I cannot obtain
> the same result. I am guessing it does not use the -d option.

Humm, it should be working, i.e. -d processing is about adding a filter,
lemme see...

Yeah, in builtin-annotate.c

OPT_STRING('d', "dsos", &symbol_conf.dso_list_str, "dso[,dso...]",
"only consider symbols in these dsos"),

It sets the dso_list_str and that is used when processing events in:

perf_session__process_events
process_sample_event (in builtin-annotate.c)
event__preprocess_sample

In event__preprocess_sample:

if (symbol_conf.dso_list &&
(!al->map || !al->map->dso ||
!(strlist__has_entry(symbol_conf.dso_list,
al->map->dso->short_name) ||
(al->map->dso->short_name != al->map->dso->long_name &&
strlist__has_entry(symbol_conf.dso_list,
al->map->dso->long_name)))))
goto out_filtered;

Yeah, this is all done no matter what frontend is used :-\

I just tried it here with:

[root(a)emilia linux-2.6-tip]# perf report -d libc-2.12.so
[root(a)emilia linux-2.6-tip]# perf annotate -d libc-2.12.so

with

[root(a)emilia linux-2.6-tip]# cat ~/.perfconfig
[tui]

report = on
annotate = on
[root(a)emilia linux-2.6-tip]#

And it works as expected.

- Arnaldo
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo(a)vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
From: Stephane Eranian on
On Wed, May 26, 2010 at 10:33 PM, Arnaldo Carvalho de Melo
<acme(a)infradead.org> wrote:
> Em Wed, May 26, 2010 at 10:11:14PM +0200, Stephane Eranian escreveu:
>> On Wed, May 26, 2010 at 9:32 PM, Arnaldo Carvalho de Melo
>> <acme(a)infradead.org> wrote:
>> > Em Wed, May 26, 2010 at 09:07:05PM +0200, Stephane Eranian escreveu:
>> >> But in this example, I only really care about the symbols in the
>> >> noploop program (/tmp/noploop).
>> >>
>> >> Missing symbol support for the kernel should not cause perf to avoid
>> >> trying to resolve the symbols in other modules such as my user program
>> >> here.
>> >
>> > Right, my bad, I thought that the problem was about the kernel symbols.
>> >
>> > Then can you try replacing:
>> >
>> > perf annotate -i ~/perf.data noploop
>> >
>> > with:
>> >
>> > perf annotate -i ~/perf.data -d noploop
>> >
>> > And see if that helps?
>> >
>> Ok that works. But if I turned on TUI, then I cannot obtain
>> the same result. I am guessing it does not use the -d option.
>
> Humm, it should be working, i.e. -d processing is about adding a filter,
> lemme see...
>
> Yeah, in builtin-annotate.c
>
>        OPT_STRING('d', "dsos", &symbol_conf.dso_list_str, "dso[,dso...]",
>                   "only consider symbols in these dsos"),
>
> It sets the dso_list_str and that is used when processing events in:
>
>        perf_session__process_events
>                process_sample_event (in builtin-annotate.c)
>                        event__preprocess_sample
>
> In event__preprocess_sample:
>
>     if (symbol_conf.dso_list &&
>         (!al->map || !al->map->dso ||
>          !(strlist__has_entry(symbol_conf.dso_list,
>                               al->map->dso->short_name) ||
>            (al->map->dso->short_name != al->map->dso->long_name &&
>             strlist__has_entry(symbol_conf.dso_list,
>                                al->map->dso->long_name)))))
>             goto out_filtered;
>
> Yeah, this is all done no matter what frontend is used :-\
>
> I just tried it here with:
>
> [root(a)emilia linux-2.6-tip]# perf report -d libc-2.12.so
> [root(a)emilia linux-2.6-tip]# perf annotate -d libc-2.12.so
>
> with
>
> [root(a)emilia linux-2.6-tip]# cat ~/.perfconfig
> [tui]
>
>        report = on
>        annotate = on
> [root(a)emilia linux-2.6-tip]#
>
> And it works as expected.
>
I did not explain my testcase enough ;-<

With TUI, I started from perf report -i perf.data, then chose to zoom into
the noploop symbol.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo(a)vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
From: Arnaldo Carvalho de Melo on
Em Wed, May 26, 2010 at 10:40:24PM +0200, Stephane Eranian escreveu:
> On Wed, May 26, 2010 at 10:33 PM, Arnaldo Carvalho de Melo
> > I just tried it here with:
> >
> > [root(a)emilia linux-2.6-tip]# perf report -d libc-2.12.so
> > [root(a)emilia linux-2.6-tip]# perf annotate -d libc-2.12.so
> >
> > with
> >
> > [root(a)emilia linux-2.6-tip]# cat ~/.perfconfig
> > [tui]
> >
> > � � � �report = on
> > � � � �annotate = on
> > [root(a)emilia linux-2.6-tip]#
> >
> > And it works as expected.

> I did not explain my testcase enough ;-<
>
> With TUI, I started from perf report -i perf.data, then chose to zoom into
> the noploop symbol.

You can zoom into DSOs and threads, additionally you can Annotate
symbols, so you mean that annotating the 'noploop' in the 'noploop' DSO
didn't work?

Lets try this offline thing ourselves, can you please put the
perf.data.tar.bz2 and the perf.data files somewhere I can grab? So that
I can try to do these operations here and figure out the problem :-)

I guess there is nothing sensitive in those files, lemme know if making
them available is not an option and I'll try other ways to get this
fixed.

- Arnaldo
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo(a)vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
From: Stephane Eranian on
On Wed, May 26, 2010 at 10:50 PM, Arnaldo Carvalho de Melo
<acme(a)infradead.org> wrote:
> Em Wed, May 26, 2010 at 10:40:24PM +0200, Stephane Eranian escreveu:
>> On Wed, May 26, 2010 at 10:33 PM, Arnaldo Carvalho de Melo
>> > I just tried it here with:
>> >
>> > [root(a)emilia linux-2.6-tip]# perf report -d libc-2.12.so
>> > [root(a)emilia linux-2.6-tip]# perf annotate -d libc-2.12.so
>> >
>> > with
>> >
>> > [root(a)emilia linux-2.6-tip]# cat ~/.perfconfig
>> > [tui]
>> >
>> >        report = on
>> >        annotate = on
>> > [root(a)emilia linux-2.6-tip]#
>> >
>> > And it works as expected.
>
>> I did not explain my testcase enough ;-<
>>
>> With TUI, I started from perf report -i perf.data, then chose to zoom into
>> the noploop symbol.
>
> You can zoom into DSOs and threads, additionally you can Annotate
> symbols, so you mean that annotating the 'noploop' in the 'noploop' DSO
> didn't work?
>
Yes, it does not show me the assembly.

> Lets try this offline thing ourselves, can you please put the
> perf.data.tar.bz2 and the perf.data files somewhere I can grab? So that
> I can try to do these operations here and figure out the problem :-)
>
> I guess there is nothing sensitive in those files, lemme know if making
> them available is not an option and I'll try other ways to get this
> fixed.
>
I will send you the files in a private email.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo(a)vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/