On 06/01/2017 03:17 AM, Stephane Eranian wrote: > Hi, > > So if I understand, the problem is that you compile PAPI against a > libpfm which is different from the one actually installed on the > system. If the system has a more recent libpfm with more PMUs, that > means PAPI's PFM_PMU_MAX < actual PFM_PMU_MAX. That should not be a > problem. But the opposite is. > I agree that having the PFM_PMU_MAX in that enum as part of the ABI of > the library is not so good for compatibility. There is not much I can > do at this point to remove it. It is part of the ABI. You cannot > easily remove it from the enum and provide a macro instead, as > suggested by Steve, because you may have user code doing: int > pmus[PFM_PMU_MAX]. I don't think compiler would accept a while loop in > there. > > I can certainly cleanup the internals of the library to not use > PFM_PMU_MAX and allocate dynamically and count the actual number of > entries on initialization. We could have the compiler generate a > warning whenever it sees PFM_PMU_MAX used. But that's probably about > it. > > Any other suggestions? >
Hi Stephane, Yes, the description above is a decent summary of the issue. What would like to do is avoid that undesirable dependency on the build environment's PFM_PMU_MAX. Just removing PFM_PMU_MAX from existing header file would cause code to break and adding some variable in libpfm that contained the value of PFM_PMU_MAX would cause an abi change to libpfm. As a workaround I made a proposed patch for PAPI that takes a closer look at the error return codes of pfm_get_pmu_info. If the return code is PFM_ERR_NOTSUPP, it figures that there was actual pmu entry and continues searching. Is that a reasonable assumption on how pfm_get_pmu_info will work? This patch is posted on https://groups.google.com/a/icl.utk.edu/forum/#!topic/ptools-perfapi/Dx3xjwxplWo -Will ------------------------------------------------------------------------------ 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
