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.