On 29/05/18 16:48, Arnaldo Carvalho de Melo wrote: > Hi Adrian, > > We've made tools/perf/check-headers.sh the mechanism to check > for drift on kernel file copies we have in tools/, and it assumes that > if we have tools/a/b/c/d, then it came from a/b/c/d in the kernel > sources, e.g. a copy of the kernel's arch/x86/lib/x86-opcode-map.txt > would be in tools/arch/x86/lib/x86-opcode-map.txt. > > That is not the case with the intel-pt-decoder, so I'm thinking > about moving those files to comply with the model used for other copies, > as having it in util/intel-pt-decoder/ isn't strictly required, i.e. > those files could conceivably be used for other purposes besides > decoding intel-pt traces, say for disassembly/annotate, that albeit not > planned (at least by me) for the near future, would be something > interesting to investigate doing. > > IIRC Ingo was the one to point me out this, and now I saw the > warning about it being different flying by in the middle of the build, > differently from what is done by check-headers.sh, that is to show > everything that drifted in one single block, at the start of the build. > > So unless you have a strong objection to this, I'll continue > investigation about how do do it with tools/perf/check-headers.sh,
I have no objection but currently it is (theoretically) possible to compile Intel PT decoding support into perf script and perf report for any architecture. i.e. decoding Intel PT from a perf.data file does not depend on the build architecture.
