An issue was noted while running tests in windows debug mode on the latest
development library.
As noted in the patch commit message, an initialisation issue for the
output packet structure was highlighted by the windows debug memory
initialisation (0xcdcdcdcd) which did not show up in linux tests (probably
due to default 0 init).
This led to the discovery of an additional issue with the setting of the
.isa field in the instruction range output packets. Prior to the patch this
was defaulting …
[View More]AArch32 in linux and not always being set correctly in the
ETMv4 and PTM decoders The default for PTM was probably OK in none-thumb
cases but the AArch64 juno captures were consistently reporting AArch32 in
the output packets which should have been AArch64.
The updated release has been tested against the opencsd-perf-4.7-rc4 build
of the perf report/script tools.
As expected the output from perf report is unchanged.
However, the perf script, which runs the architecture based disassembly is
also unchanged, suggesting that this code is not at present taking note of
the ISA supplied by the trace output.
Running against both the unpatched library, with packets marked as AArch32,
and the patched library, with packets marked as AArch64, resulted in the
disassembly correctly being output as AArch64.
I assume that the disassembly routines are obtaining the current core arch
from other information in the perf.data file. We should probably consider
if this is the best way to go in this case.
Regards
Mike
--
Mike Leach
Principal Engineer, ARM Ltd.
Blackburn Design Centre. UK
[View Less]
Patch updates the handler function in cs-etm-decoder to deal with a new generic packet type introduced in the latest decoder.
Mike Leach (1):
cs-etm: Update to cs-etm-decoder to handle new packet type from
OpenCSD.
tools/perf/util/cs-etm-decoder/cs-etm-decoder.c | 6 +-----
1 file changed, 1 insertion(+), 5 deletions(-)
--
1.9.1
Additional Generic element type was added in OpenCSD 0v003 (ETMv3 additions) - this broke the perf build as it was missing from the case statement handling the enum types.
Patch fixes this - generated relative to perf-opencsd-4.7-rc1 branch
Mike Leach (1):
csetm: Update to cs-etm-decoder to handle new packet type.
tools/perf/util/cs-etm-decoder/cs-etm-decoder.c | 1 +
1 file changed, 1 insertion(+)
--
1.9.1
Good day all,
Here's the first draft of the "abstract" I intend to submit for ELC-E
in Berlin. Keeping in mind the 900 character limit (this is already
880), please have a read and get back to me with your thoughts.
[Begin]
The CoreSight framework available in the Linux kernel has recently
been integrated with the Perf core, making HW assisted tracing on ARM
systems accessible to developers working on a wide spectrum of
products. This presentation will start by giving a brief overview of
…
[View More]the CoreSight technology itself before presenting the current
solution, from trace collection in kernel space to off system trace
decoding. To help with the latter part the Open CoreSight Decoding
Library (openCSD) is introduced. OpenCSD is an open source library
assisting in the decoding of collected trace data. We will see how it
is used with the existing perf tools to provide an end-to-end solution
for CoreSight trace decoding. The presentation will conclude with
trace acquisition and decoding scenarios, along with tips on how to
interpret trace information rendered by the perf tools.
[End]
Many thanks,
Mathieu
[View Less]
Hello Tor,
While ramping up on the "perf report" and "perf script" features I fixed
a few things and decided to play a little:
1/4: No influence on the current results but good to fix.
2/4: That changes a lot of things when multiple buffers have been collected.
3/4: No change in functionality, just cleanup.
4/4: Enhancement to make the output easier to read.
These changes can be found here[1]. If this is good with you I'll push them
to gitHub for the 4.7 cycle.
Regards,
Mathieu
[1]. https:…
[View More]//git.linaro.org/people/mathieu.poirier/coresight.git/shortlog/refs/h…
Mathieu Poirier (4):
cs-etm: avoid casting variable
cs-etm: account for each trace buffer in the queue
cs-etm: removing unecessary structure field
cs-etm: associating output packet with CPU they executed on
tools/perf/scripts/python/cs-trace-disasm.py | 2 +
tools/perf/util/cs-etm-decoder/cs-etm-decoder.c | 15 +++-
tools/perf/util/cs-etm-decoder/cs-etm-decoder.h | 1 +
tools/perf/util/cs-etm.c | 103 +++++++++++++++++++-----
tools/perf/util/cs-etm.h | 7 ++
5 files changed, 106 insertions(+), 22 deletions(-)
--
2.5.0
[View Less]
Hi Tor,
Running through the ETMv3 decode is making me think a bit more about the generic output packets.
For ETMv4, we output a OCSD_GEN_TRC_ELEM_PE_CONTEXT to indicate context info for the core, then a string of OCSD_GEN_TRC_ELEM_INSTR_RANGE for the instructions executed with the context.
This mirrors the way ETMv4 packet streams work.
ETMv3 and to a lesser extent PTM handles context differently, meaning we have to work harder to output the a OCSD_GEN_TRC_ELEM_PE_CONTEXT prior to the …
[View More]OCSD_GEN_TRC_ELEM_INSTR_RANGE packets.
It occurs to me that the context packet is only really relevant when processing the instruction ranges (and possibly for data tracing later on), so I was considering:-
1) Mandating that the context part of the generic packet structure is valid for the instruction range packet (it happens to be for the current decoder, but that is a consequence of how it is written rather than a deliberate rule). In future it can be mandated for data packets if required.
2) Dropping the OCSD_GEN_TRC_ELEM_PE_CONTEXT packets completely.
For the decoders this mandate is not onerous as they have to maintain the current context anyway to do the decode. Dropping a packet could simplify both decoder and library client operation.
How would this affect the current perf decode?
After the ETMv3 dev (or possibly at the end of it), I am going to expand the docs for the generic packets to set down these rules and dependencies.
Regards
Mike
----------------------------------------------------------------
Mike Leach +44 (0)1254 893911 (Direct)
Principal Engineer +44 (0)1254 893900 (Main)
Arm Blackburn Design Centre +44 (0)1254 893901 (Fax)
Belthorn House
Walker Rd mailto:mike.leach@arm.com
Guide
Blackburn
BB1 2QE
----------------------------------------------------------------
IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.
[View Less]
Hi,
I'd like to get your thoughts on an appropriate low-level userspace API for STM.
The API I'm after would assume the ability to map a range of channels into
userspace as detailed in Documentation/trace/stm.txt:
"Some STM devices may allow direct mapping of the channel mmio region
to userspace for zero-copy writing..."
What that doesn't describe is what you do with the region once you've got it.
Which suggests a userspace API that can abstract over the way channels are
represented in the …
[View More]memory map, i.e. how bits of the address are used to
influence the data packets. Given a channel number (or a relative channel
number) and some data, it would generate a store to the right address,
or an lvalue at the right address. So you could write something like this:
STM_TRACE_DATA(p, TIMESTAMP, uint32, 123);
or perhaps
*STM_TRACE_CHANNEL(p, TIMESTAMP, uint32) = 123;
and this would become inline code that would be a single store that would
cause a D32 packet. The ARM and Intel implementations would differ
in how they calculated the address and perhaps on whether some features
were available. 64-bit writes would be unavailable on some ARM systems.
Userspace libraries that implemented higher-level messaging formats could
then sit on top of this lower-level API.
I don't think I've seen this in any of the patches that have come round but is
anyone working on anything like this?
Al
[View Less]