Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > linux.kernel > #1415989
| From | Alexander Shishkin <alexander.shishkin@linux.intel.com> |
|---|---|
| Newsgroups | linux.kernel |
| Subject | Re: [RFC PATCH 0/4] Integration of function trace with System Trace IP blocks |
| Date | 2016-06-07 13:00 +0200 |
| Message-ID | <rHmTL-1Cx-21@gated-at.bofh.it> (permalink) |
| References | <rFclP-7HG-3@gated-at.bofh.it> |
| Organization | linux.* mail to news gateway |
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
Back to linux.kernel | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread
[RFC PATCH 0/4] Integration of function trace with System Trace IP blocks Chunyan Zhang <zhang.chunyan@linaro.org> - 2016-06-01 13:20 +0200
[RFC PATCH 3/4] trace: Duplicate the output of the function trace logs to STM Chunyan Zhang <zhang.chunyan@linaro.org> - 2016-06-01 13:20 +0200
Re: [RFC PATCH 3/4] trace: Duplicate the output of the function trace logs to STM Alexander Shishkin <alexander.shishkin@linux.intel.com> - 2016-06-07 12:10 +0200
Re: [RFC PATCH 3/4] trace: Duplicate the output of the function trace logs to STM Chunyan Zhang <zhang.chunyan@linaro.org> - 2016-06-08 13:10 +0200
Re: [RFC PATCH 0/4] Integration of function trace with System Trace IP blocks Alexander Shishkin <alexander.shishkin@linux.intel.com> - 2016-06-07 13:00 +0200
Re: [RFC PATCH 0/4] Integration of function trace with System Trace IP blocks Chunyan Zhang <zhang.chunyan@linaro.org> - 2016-06-08 13:10 +0200
csiph-web