Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > linux.kernel > #1415989

Re: [RFC PATCH 0/4] Integration of function trace with System Trace IP blocks

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

Show all headers | View raw


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 | NextPrevious in thread | Next in thread | Find similar | Unroll thread


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