Messages in this thread | | | From | Alexander Shishkin <> | Subject | Re: [RFC PATCH 0/4] Integration of function trace with System Trace IP blocks | Date | Tue, 07 Jun 2016 13:50:22 +0300 |
| |
Chunyan Zhang <zhang.chunyan@linaro.org> writes:
> This patchset is an RFC aimed at generating ideas on the best way to > use STM IP blocks to collect function tracing information produced by > Ftrace. That way logging information generated by the function trace > subsystem and gathered in the coresight sink can be used in conjunction > with trace data from other board components, also collected in the same > trace sink. This example is using ARM coresight STM but the same would > apply to any architecture wishing to do the same.
I'd say, traces are only useful if you can make sense of them. This patchset basically sends out addresses, which only makes sense if the decoding side has vmlinux of the kernel under tracing. But even if they do, other context information is still missing, such as the cpu ids of these events, without which you can't really tell what's been going on. You can, of course, still use this data for coverage analysis, but there are easier ways of doing that already.
So I'd say that first you need to export at least as much as is written to the ftrace ring buffer. And perhaps, to avoid inventing yet another binary protocol, it would have to be exactly what is written to the ftrace ring buffer.
Then you need to think whether you want to export binary ftrace data or ascii-formatted strings: * binary data is way less overhead; * ascii data is self-contained; * binary data requires the exact running kernel's binaries to decode and the ability to read them (say, if you wanted to read the traces on some other OS that doesn't have native support for ELF binaries); every time you recompile the target kernel, you'll have to copy it over to the debug host; * ascii data can be looked at independently.
That's off the top of my head.
Regards, -- Alex
| |