[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20091215023228.GC6048@nowhere>
Date: Tue, 15 Dec 2009 03:32:30 +0100
From: Frederic Weisbecker <fweisbec@...il.com>
To: Arnaldo Carvalho de Melo <acme@...stprotocols.net>
Cc: mingo@...hat.com, hpa@...or.com, paulus@...ba.org,
linux-kernel@...r.kernel.org, a.p.zijlstra@...llo.nl,
efault@....de, tglx@...utronix.de, mhiramat@...hat.com,
mingo@...e.hu, linux-tip-commits@...r.kernel.org
Subject: Re: [tip:perf/urgent] perf symbols: Allow lookups by symbol name
too
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 :)
--
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