libpfm4: reserved_bits:12

Issue #126 resolved
Anustuv Pal created an issue

This issue is made from a comment at https://bitbucket.org/icl/papi/pull-requests/367

Shouldn’t reserved_bits:12 be bumped up to account for the removed bitmasks?

papi/src$ grep -rnI reserved_bits

Shows the following output,

perfctr-2.7.x/linux/drivers/perfctr/x86.c:257:               unsigned int reserved_bits, int is_c6)
perfctr-2.7.x/linux/drivers/perfctr/x86.c:276:      if ((evntsel & reserved_bits) != 0)
libpfm4/include/perfmon/pfmlib.h:730:       unsigned int    reserved_bits:30;
libpfm4/include/perfmon/pfmlib.h:759:       unsigned int    reserved_bits:28;
libpfm4/include/perfmon/pfmlib.h:777:       unsigned int    reserved_bits:27;
libpfm4/lib/pfmlib_common.c:2222:   uinfo->reserved_bits = 0;
libpfm4/lib/pfmlib_priv.h:75:       unsigned int    reserved_bits:27;
libpfm4/docs/man3/pfm_get_event_info.3:29:          unsigned int reserved_bits:31;
papi.h:677:     unsigned int reserved_bits:12;
install/include/papi.h:677:     unsigned int reserved_bits:12;
install/include/perfmon/pfmlib.h:730:       unsigned int    reserved_bits:30;
install/include/perfmon/pfmlib.h:759:       unsigned int    reserved_bits:28;
install/include/perfmon/pfmlib.h:777:       unsigned int    reserved_bits:27;
install/share/man/man3/pfm_get_event_info.3:29:          unsigned int reserved_bits:31;
install/share/man/man3/PAPI_component_info_t.3:115:.RI "unsigned int \fBreserved_bits\fP:12"
perfctr-2.6.x/linux/drivers/perfctr/x86.c:265:               unsigned int reserved_bits, int is_c6)
perfctr-2.6.x/linux/drivers/perfctr/x86.c:281:      if ((evntsel & reserved_bits) != 0)

There is no mention of reserved_bits:12. This seems to be a libpfm4 issue

Comments (6)

  1. Steve Kaufmann

    It is right there in src/papi.h, line 655 in the latest source: unsigned int reserved_bits:12;

    Because of removed bit-field members this should be reserved_bits:19 to pad out to 32-bits. In fact, the padding should be in the upper 32-bits of an int and not the lower 32-bits so that padding is less likely to be disrupted (new bit-fields then added in the upper bits).

    So this is really a PAPI issue.

  2. Log in to comment