On Sat, Dec 12, 2009 at 07:22:03AM +0000, tip-bot for Arnaldo Carvalho de Melo wrote:
> Commit-ID: 79406cd789f745ac6aa9d597895f904a98a14007
> Gitweb: http://git.kernel.org/tip/79406cd789f745ac6aa9d597895f904a98a14007
> Author: Arnaldo Carvalho de Melo <[email protected]>
> AuthorDate: Fri, 11 Dec 2009 18:50:22 -0200
> Committer: Ingo Molnar <[email protected]>
> CommitDate: Sat, 12 Dec 2009 07:42:11 +0100
>
> perf symbols: Allow lookups by symbol name too
>
> Configurable via symbol_conf.sort_by_name, so that the cost of an
> extra rb_node on all 'struct symbol' instances is not paid by tools
> that only want to decode addresses.
>
> How to use it:
>
> symbol_conf.sort_by_name = true;
> symbol_init(&symbol_conf);
>
> struct map *map = map_groups__find_by_name(kmaps, MAP__VARIABLE, "[kernel.kallsyms]");
>
> if (map == NULL) {
> pr_err("couldn't find map!\n");
> kernel_maps__fprintf(stdout);
> } else {
> struct symbol *sym = map__find_symbol_by_name(map, sym_filter, NULL);
> if (sym == NULL)
> pr_err("couldn't find symbol %s!\n", sym_filter);
> else
> pr_info("symbol %s: %#Lx-%#Lx \n", sym_filter, sym->start, sym->end);
> }
>
> Looking over the vmlinux/kallsyms is common enough that I'll add a
> variable to the upcoming struct perf_session to avoid the need to
> use map_groups__find_by_name to get the main vmlinux/kallsyms map.
>
> The above example looks on the 'variable' symtab, but it is just
> like that for the functions one.
>
> Also the sort operation is done when we first use
> map__find_symbol_by_name, in a lazy way.
It would be nice to also have a kernel symbol resolution
helper independant of any session.
The problem is that I need to resolve a kernel variable symbol
very early, when we parse record options. We don't have any
session at this time so I can't retrieve the kmaps.
I'm not sure what's the proper way to handle that.
Thanks.
Em Tue, Dec 15, 2009 at 03:12:03AM +0100, Frederic Weisbecker escreveu:
> On Sat, Dec 12, 2009 at 07:22:03AM +0000, tip-bot for Arnaldo Carvalho de Melo wrote:
> > Looking over the vmlinux/kallsyms is common enough that I'll add a
> > variable to the upcoming struct perf_session to avoid the need to
> > use map_groups__find_by_name to get the main vmlinux/kallsyms map.
> >
> > The above example looks on the 'variable' symtab, but it is just
> > like that for the functions one.
> >
> > Also the sort operation is done when we first use
> > map__find_symbol_by_name, in a lazy way.
>
> It would be nice to also have a kernel symbol resolution
> helper independant of any session.
>
> The problem is that I need to resolve a kernel variable symbol
> very early, when we parse record options. We don't have any
> session at this time so I can't retrieve the kmaps.
Humm, I don't think that is a problem, we just have to create the
session before processing the args, after all at record time we can use
kallsyms already.
> I'm not sure what's the proper way to handle that.
What is the problem? I'm not following :-)
- Arnaldo
On Tue, Dec 15, 2009 at 12:20:20AM -0200, Arnaldo Carvalho de Melo wrote:
> Em Tue, Dec 15, 2009 at 03:12:03AM +0100, Frederic Weisbecker escreveu:
> > On Sat, Dec 12, 2009 at 07:22:03AM +0000, tip-bot for Arnaldo Carvalho de Melo wrote:
> > > Looking over the vmlinux/kallsyms is common enough that I'll add a
> > > variable to the upcoming struct perf_session to avoid the need to
> > > use map_groups__find_by_name to get the main vmlinux/kallsyms map.
> > >
> > > The above example looks on the 'variable' symtab, but it is just
> > > like that for the functions one.
> > >
> > > Also the sort operation is done when we first use
> > > map__find_symbol_by_name, in a lazy way.
> >
> > It would be nice to also have a kernel symbol resolution
> > helper independant of any session.
> >
> > The problem is that I need to resolve a kernel variable symbol
> > very early, when we parse record options. We don't have any
> > session at this time so I can't retrieve the kmaps.
>
> Humm, I don't think that is a problem, we just have to create the
> session before processing the args, after all at record time we can use
> kallsyms already.
Yeah but we need the output filename before creating it, which
we even don't have yet at this time.
May be I should just init it very early without the filename
and assign it later with a small new helper.
Another problem is that the record session is not available
from parse-events.c, may be should I create a single wide scope
record_session that would be shared among record, top and stat
so that it's available from parse-event.c
>
> > I'm not sure what's the proper way to handle that.
>
> What is the problem? I'm not following :-)
I think the real problem actually is that I should join
my bed.
The above questions will retrieve their trivial essence after
some sleep :)
Em Tue, Dec 15, 2009 at 03:32:30AM +0100, Frederic Weisbecker escreveu:
> On Tue, Dec 15, 2009 at 12:20:20AM -0200, Arnaldo Carvalho de Melo wrote:
> > Em Tue, Dec 15, 2009 at 03:12:03AM +0100, Frederic Weisbecker escreveu:
> > > On Sat, Dec 12, 2009 at 07:22:03AM +0000, tip-bot for Arnaldo Carvalho de Melo wrote:
> > > > Looking over the vmlinux/kallsyms is common enough that I'll add a
> > > > variable to the upcoming struct perf_session to avoid the need to
> > > > use map_groups__find_by_name to get the main vmlinux/kallsyms map.
> > > >
> > > > The above example looks on the 'variable' symtab, but it is just
> > > > like that for the functions one.
> > > >
> > > > Also the sort operation is done when we first use
> > > > map__find_symbol_by_name, in a lazy way.
> > >
> > > It would be nice to also have a kernel symbol resolution
> > > helper independant of any session.
> > >
> > > The problem is that I need to resolve a kernel variable symbol
> > > very early, when we parse record options. We don't have any
> > > session at this time so I can't retrieve the kmaps.
> >
> > Humm, I don't think that is a problem, we just have to create the
> > session before processing the args, after all at record time we can use
> > kallsyms already.
>
> Yeah but we need the output filename before creating it, which
> we even don't have yet at this time.
Well, see top it should shed some light:
/*
* FIXME: perf_session__new should allow passing a O_MMAP, so that all this
* mmap reading, etc is encapsulated in it. Use O_WRONLY for now.
*/
struct perf_session *session = perf_session__new(NULL, O_WRONLY, false,
&symbol_conf);
8-)
> May be I should just init it very early without the filename
> and assign it later with a small new helper.
>
> Another problem is that the record session is not available
> from parse-events.c, may be should I create a single wide scope
> record_session that would be shared among record, top and stat
> so that it's available from parse-event.c
>
> > > I'm not sure what's the proper way to handle that.
> >
> > What is the problem? I'm not following :-)
>
> I think the real problem actually is that I should join
> my bed.
> The above questions will retrieve their trivial essence after
> some sleep :)
Ok, I'm some hours behind you but neverthless ahead of my own bedtime,
lets see tomorrow how to add support for your scenario and for O_MMAP
before some other top-like app needs to use our mutant teenage libperf
kid :-)
- Arnaldo