aboutsummaryrefslogtreecommitdiff
path: root/tools/build/cross-build/Makefile
diff options
context:
space:
mode:
authorJessica Clarke <jrtc27@FreeBSD.org>2023-06-07 14:21:18 +0000
committerJessica Clarke <jrtc27@FreeBSD.org>2023-06-07 14:24:29 +0000
commit21f7397a61f7bff61a1221cc6340cd980a922540 (patch)
tree1b2960e78f22a93c849fe84ff6449dde4e355ec4 /tools/build/cross-build/Makefile
parent296a0987be590e73784e4c313d28a61ff310f1a3 (diff)
downloadsrc-21f7397a61f7bff61a1221cc6340cd980a922540.tar.gz
src-21f7397a61f7bff61a1221cc6340cd980a922540.zip
libpmc: Handle PMCALLOCATE log with PMC code on PMU event system
On an arm64 system that reports as a Cortex A72 r0p3, running pmcstat -P CPU_CYCLES command works, but pmcstat -P cpu-cycles command does not. This is because the former uses the PMU event from the JSON source, resulting in pl_event in the log event being a small index (here, 5) into the generated events table, whilst the latter does not match any of the JSON events and falls back on PMC's own tables, mapping it to the PMC event 0x14111, i.e. PMC_EV_ARMV8_EVENT_11H. Then, when libpmc gets the PMCALLOCATE event, it tries to use the event as an index into the JSON-derived table, but doing so only makes sense for the former, whilst for the latter it will go way out of bounds and either read junk (which may trigger the != NULL assertion) or segfault. As far as I can tell we don't have anything lying around to tell us which of the two cases we're in, but we can exploit the fact that the first 0x1000 PMC event codes are reserved, and that none of our PMU events tables reach that number of entries yet. PR: 268857 Reviewed by: mhorne MFC after: 1 month Differential Revision: https://reviews.freebsd.org/D39592
Diffstat (limited to 'tools/build/cross-build/Makefile')
0 files changed, 0 insertions, 0 deletions