Hi Will, On Thu, Jun 1, 2017 at 7:16 AM, William Cohen <wco...@redhat.com> wrote: > 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?
Looking at the current code, your assumption is correct. If the pmu index is beyond PFM_PMU_MAX and everything is okay, then you will get PFM_ERR_INVAL. You get PFM_ERR_NOTSUPP, if the PMU is implemented but not detected on host hardware. So you can use as a substitute to PFM_PMU_MAX to get the total number of detected PMUs or total number of implemented PMUs (if you include NOTSUPP). As an extension, I can add a new entrypoint to return this info. That would certainly be cleaner, though, it would not solve your problem with existing releases. > > 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
