stephane eranian wrote: > On Fri, Oct 30, 2009 at 6:41 PM, Corey Ashford > <cjash...@linux.vnet.ibm.com> wrote: >> Hi Stephane, >> >> I wonder if you have considered this possibility for getting symbolic event >> naming ability into the perf tool: >> >> Create a wrapper program, call it "sperf" (for symbolic perf), and what it >> would do is scan the command line for any -e (event) switches. If it finds >> a -e switch, it would try running the event string through libpfm's function >> to produce a config value. If that failed, it would leave the event alone >> (for the case where the events are recognized only by the perf tool). If it >> passed, you'd replace that symbol with the calculated config hex value with >> an 'r' pre-pended to it. Once all of the arguments are processed, you call >> the perf with this set of arguments. >> >> sperf could be built anywhere that has visibility to libpfm, and it would >> find the perf tool by using >> /lib/modules/`uname -r`/source/tools/perf/perf >> or it could be overridden by an environment variable, say "PERF_PATH". >> >> We have a near-term need for such a tool, and I will likely be prototyping >> this idea soon. >> > That's one way of doing it without touching perf. > > The other way would be to have perf try to dlopen() libpfm4. It is finds it > then > it can handle more symbolic events internally, otherwise it runs with > its builtin > events and rXXX notation.
I considered the shared object approach too, but it would have to be carefully constructed so that we could get the patch accepted upstream eventually. Perhaps it would have to be very generic, and not require libpfm4 specifically. For example, perf could try just to import a function with the profile "int perf_xlate_symb_event_to_config(const char *, u64 *config);", and libpfm4 could export such a thing, or a "gasket library" for libpfm4 could export such a thing. I think this "don't touch perf" approach definitely has some appeal, though, since it won't require patches, or getting anything upstream. So the latter could be the short-term approach, and the former perhaps a longer-term approach, since it would benefit perf to have such an interface. The one difficult part of the shared object approach, is that if you don't have things set up just right, perf will silently fail to find your shared object, and resort to its internal processing. So perhaps in the perf patch we'd need to put in some narrative, enabled with the verbose option, that describes where perf is looking for the object, and what sort of error it encountered when it found a candidate object (for example 32-/64-bit object mismatch). Whereas with the "don't touch perf" wrapper approach, if it can't find perf, it just doesn't work at all, and will give a nice error without any verbose options needed. -- Regards, - Corey Corey Ashford Software Engineer IBM Linux Technology Center, Linux Toolchain Beaverton, OR 503-578-3507 cjash...@us.ibm.com ------------------------------------------------------------------------------ Come build with us! The BlackBerry(R) Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9 - 12, 2009. Register now! http://p.sf.net/sfu/devconference _______________________________________________ perfmon2-devel mailing list perfmon2-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/perfmon2-devel
