Matheiu Poirier wrote:
On Wed, 8 Jul 2020 at 10:04, Al Grant Al.Grant@arm.com wrote:
While running perf on some function-heavy code I noticed the ETM return stack
isn’t enabled (TRCCONFIGR bit 9). I know that it can easily be enabled with retstack=1,
but have we considered making this the default as we move to simplification of
perf options? It could lead to more efficient profiles and shouldn’t be any more
difficult to decode than ETM normally is.
Can you give me more details on this simplification of the perf options you are referring to?
I was thinking of the implicit sinks proposal, which will mean that most of the time we can say simply
perf record -e cs_etm// ...
The easier it is to use, the more useful it is for the default settings to be the most useful ones.
I am debating whether the result of a perf trace session is a user visible change and I haven't made up my mind yet. I am personally fine with enabling the return stack option by default but if somebody yells then we might have to rever the patch. It would be nice to hear back from users on this list - is anyone strongly opinionated on this?
OpenCSD can cope, so it should all be transparent, the only impact I can see is people doing their own trace decode, with a simplistic decoder that can't handle the return stack, and who were relying on it being disabled by default. There may be some code where there's difficulty accessing the original image and the explicit return addresses are useful - but in that situation you might also struggle to follow the E/N atoms and need to enable branch-broadcast (which causes even more bloat in the trace).
The ETM spec allows for considerable variation between implementations - anything that's making assumptions about the way ETM trace looks, based on what it's looked like in the past, is likely to break anyway.
Al
Thanks, Mathieu
Al
CoreSight mailing list CoreSight@lists.linaro.org https://lists.linaro.org/mailman/listinfo/coresight