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-tip-commits" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
|