Stephane (and others),


It turns out that PAPI uses pfm_find_event() to get back an event index that is then passed to pfm_get_event_info() to get the events information structure.  This contains a pmu id which is passed to pfm_get_pmu_info() to get the pmu short name.  All of this is done so that PAPI can build a full event name (pmu::event:masks).


So far I have not been able to find any other way to get the pmu id or pmu name from libpfm4.  The pfm_get_os_event_encoding() function takes an argument block that contains a “char **fstr” that is described as a fully qualified event string.  So I gave it a char ** to some space in the caller but it does not seem to return anything.


Can anyone tell me another way to get the pmu name for a supplied event string that did not contain a pmu part.  If I can solve this problem, I think that PAPI will be able to use events without calling pfm_find_event() anymore. 


However these changes have caused significant damage to the papi logic that lists events.  The papi_native_avail tool now only lists about 9 core events on a SNBEP system.  I know there are lots more than that but have not had time to look into this yet.