Hi,
I'd like to see if anyone is currently using piped mode in perf. For example:
perf record -o - ls > stdio.data cat stdio.data | ./perf report -i -
This invokes a slightly different code path where there is no auxtrace index and no random file access available. Because of this, the outcome of decoding can be very subtly different. For example only one auxtrace buffer could be read at the point where decoding starts. Whereas with normal mode, all the buffers are queued in advance because of the availability of the index and random access.
A few of the changes I've proposed recently have added even more dependency on normal mode and won't work in piped mode either. For example "perf cs-etm: Support TRBE (unformatted decoding)" and "perf cs-etm: Split Coresight decode by aux records".
The reason that I made these changes in this way was because it was much more difficult to juggle the order of events and make sure nothing regressed, with the knowledge that there are already inaccuracies in piped mode and not knowing if it was even used.
The question is: whether we continue to support this for Coresight as it becomes more and more divergent to piped mode.
There are some possible outcomes that I can think of:
* Drop the mode completely * Add a warning that it's only best effort in that mode and continue with the divergence * Fix it up first to make it behave the same as normal mode. * After fixing it up, require that all future decoding behaves identically in both modes * Then we can more comfortably re-do my above two changes
Thanks James