Hi,
I've encountered a perf.data file whose PERF_RECORD_AUXTRACE_INFO has an additional ETM register per CPU (i.e. the metadata for each CPU is 8 bytes longer than normal). Some patch somewhere must be adding this register for reasons unknown.
Upstream perf won't even print this file, it reports failure to process record type 70 and errors out. The metadata reading code in util/cs-etm.c expects exactly CS_ETMV4_PRIV_MAX registers, no more. I.e. it won't go skipping past extra ones to find the next "magic" number.
It's unfortunate that "perf report -D" errors out, when the reason for using -D may be to investigate why perf in general isn't working. I want to fix this at least.
Now firstly, has anyone got any ideas why there might be an additional register, does anyone know of a patch that does this?
And secondly, could/should we make the metadata format more robust? Cases of more or fewer registers than expected can, to some extent, be handled by looking for the magic number, but that assumes that registers don't legitimately have values equal to the magic number.
The version number could help us evolve upstream to a new format but it isn't really an answer to robust interchange in general. Should we at least have the metadata describe its own length (i.e. number of registers) so that perf tools can read it, even if they might not be able to fully understand it.
Al