Hi Al,
On Tue, Nov 24, 2020 at 04:53:04PM +0000, Al Grant wrote:
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.
So firstly check one thing: is this perf.data file generated by your local machine (and you could see the corresponding code)? Or if this perf.data file is shared by others so you have no chance to check the perf source code?
If it's the first case, you could check the file arch/arm/util/cs-etm.c.
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.
Yeah, I think some minor hacking can workaround the incompatible issue.
Now firstly, has anyone got any ideas why there might be an additional register, does anyone know of a patch that does this?
You could see that ETMv4 metadata was introduced by the commit a818c563ae166 ("perf tools: Add coresight etm PMU record capabilities") since Sept, 2016. So for the mainline kernel, the metadata has not been changed for a long while.
If this perf.data is generated by any branch rather than Linux mainline kernel, I suspect if someone uses a self maintained patch and adds an extra entry into metadata, we cannot know which register's value is saved into the metadata. So I think it's better to inquiry the person who has the source code for the perf tool and check if made any change for metadata.
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.
Agreed that a self described format is better for metadata structure; I'd like to leave this question to Mathieu who might have thoughts for this.
Thanks, Leo