Hi Dominik
On Fri, 9 Apr 2021 at 15:22, Dominik Huber dominik.huber@fau.de wrote:
Hello, I want to gather trace data of closed source binaries using CoreSight ETMv4 on a Hikey620. I want to know the source and destination address for all taken jumps of the traced program, like in the output of "perf script". It would be great if I could get feedback on how to achieve this. I'm not sure where to turn to with such a broad CoreSight problem, so I'm sorry if you are not the right ones to turn to, but I'd be happy for any help or advice you might have.
This is exactly the right place to ask for help on this!
My main problem is, that I don't know which approaches are promising to try. Below I describe two Ideas that I tried but where I got stuck after a while. Are they any good for my use case? If yes, then how can I solve the respective problems that have come up, or where can I look to solve them? If not, are there maybe better ways to approach this, which I've overlooked until now?
After hearing a presentation from Mathieu Poirier, I thought sysFS was the (only) way to go. However, the decoded trace seems to show only the jump address, instead of both the source and destination addresses, and I did not find a register to change that.
What do you mean by decoded trace here & what are you using to decode the trace? If you look at the ETM spec / OpenCSD documentation you will see that to fully decode trace there is a two step process. 1) convert the trace byte stream into trace packets. This will require some minimal information regarding the configuration of the ETM 2) convert the trace packets into the fully decoded execution trace. This requires access to the binary images executed during the trace session. The reason for this is that trace packets are highly compressed, and contain the minimum of address information. Decode requires that the decoder will walk the binary images to deduce which branches are taken and not taken. Only were address information cannot be deduced from this code is included in the trace packets - and this is only ever target address information - the source address can always be deduced from the code walk.
Also, the trace gathered seems to lose some of the branch addresses. Inserting a sleep instruction after each regular instruction into my test program, fixed that. But since it should also work for closed source binaries and has to be fast this is probably not an option.
Then I tried to copy the way "perf record" is tracing, and extract the relevant code parts. But then I realized, that perf record doesn't use sysFS, apart from enabling the sink in "util/cs-etm.c" (which apparently is not used, and not even deactivated afterward).
perf uses the driver in the a similar way to sysfs. It does in fact activate and de-activate the sources and sinks as the perf events are run on any CPU. perf also records the binaries used during the trace session - so that full trace decode is possible. With sysfs you can get raw trace data - but relating this to the binaries being executed is far more difficult.
If you are interested in tracing a particular binary & this is a userspace program then you may wish to try:- perf record -e cs_etm//u --per-thread <program-to-trace> to ensure that any trace collected is related to the program you are interested in. You can then use the facilites of perf report / perf script to examine the trace.
Regards
Mike
So there is another way to gather trace, maybe by interacting with the CoreSight driver directly. But looking into the "perf report" source code I couldn't find it yet.
Thanks and regards,
Dominik
CoreSight mailing list CoreSight@lists.linaro.org https://lists.linaro.org/mailman/listinfo/coresight
-- Mike Leach Principal Engineer, ARM Ltd. Manchester Design Centre. UK