In cases like this I like to have an ending entry that is a null pointer, then
you simply loop until you see it to know you've exhausted the list:
for (i=0; pfmlib_pmus_map[i] != NULL; i++) {
....
}
Just make sure to add/update the NULL entry after populating/adding to/deleting
from the table.
Then just redefine the PFM_PMU_MAX entry something like:
#define PFM_PMU_MAX do while(0) { int _i; for(_i=0; pfmlib_pmus_map[_i]!=NULL;
_i++) { } }, _i
or perhaps a small function to do this would be cleaner:
#define PFM_PMU_MAX __pfm_count_max()
Steve
________________________________
From: William Cohen <wco...@redhat.com>
Sent: Tuesday, May 30, 2017 1:28:03 PM
To: perfmon2-devel@lists.sourceforge.net; ptools-perf...@icl.utk.edu
Cc: Michael Petlan
Subject: [ptools-perfapi] Avoid hardcoding the number of entries in the libpfm
library with PFM_PMU_MAX
Hi,
I just got done analyzing a problem where papi was built with an old verion of
the libpfm then it was being tested with a newer version of libpfm that had
support for additional processor architectures. In theory things should just
work because papi was using the libpfm shared library. However, in this case
the papi did not recognize the newer hardware's pmu. The problem was caused by
use of the PFM_PMU_MAX enum in papi's pe_libpfm4_event.c initialization loop:
for(i=0;i<PFM_PMU_MAX;i++) {
memset(&pinfo,0,sizeof(pfm_pmu_info_t));
retval=pfm_get_pmu_info(i, &pinfo);
if (retval!=PFM_SUCCESS) {
continue;
}
...
}
The older libpfm that papi was built with has a smaller value for PFM_PMU_MAX
than the newer libpfm on the system being tested. Thus, the pmu entries added
in the newer libpfm were not scanned by papi.
There should be a better way of doing this in libpfm. As new pmus are added to
libpfm the other code should not need to be recompiled because of a change to
PFM_PMU_MAX. The following in /usr/include/perfmon/libpfm.h will also cause
problems with this problem if it is used in other applications:
#define pfm_for_all_pmus(x) \
for((x)= 0 ; (x) < PFM_PMU_MAX; (x)++)
One possible way is to use the return value from pfm_get_pmu_info() to
determine whether a loop is at the end of the valid pfm_pmu_t range. Any
thoughts or comments on this?
-Will
--
You received this message because you are subscribed to the Google Groups
"ptools-perfapi" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to ptools-perfapi+unsubscr...@icl.utk.edu.
To post to this group, send email to ptools-perf...@icl.utk.edu.
Visit this group at
https://groups.google.com/a/icl.utk.edu/group/ptools-perfapi/.
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
perfmon2-devel mailing list
perfmon2-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/perfmon2-devel
