xscale: fix analyze_trace for trace data collected in wrap mode
authorMike Dunn <mikedunn@newsguy.com>
Tue, 13 Apr 2010 17:34:52 +0000 (13:34 -0400)
committerØyvind Harboe <oyvind.harboe@zylin.com>
Thu, 15 Apr 2010 17:17:31 +0000 (19:17 +0200)
commitee139164114460d5c4c1a720e28740a7dceca712
tree714b398e92a1f9950d35842d29d84b1979e51f10
parentd31bbc33fab65a27edfd142202b90011bd471406
xscale: fix analyze_trace for trace data collected in wrap mode

This patch fixes the xscale_analyze_trace() function.  This function was
defective for a trace collected in 'fill' mode (hiccups with repeated
instructions) and completely broken when buffer overflowed in 'wrap' mode.  The
reason for the latter case is that the checkpoint registers were interpreted
incorrectly when two checkpoints are present in the trace (which will be true in
'wrap' mode once the buffer fills).  In this case, checkpoint1 register will
contain the older entry, and checkpoint0 the newer.  The original code assumed
the opposite.  I eventually gave up trying to understand all the logic of the
function, and rewrote it.  I think it's much cleaner and understandable now.  I
have been using and testing this for a few weeks now.  I'm confident it hasn't
regressed in any way.

Also added capability to handle (as best as possible) the case where an
instruction can not be read from the loaded trace image; e.g., partial image.
This was a 'TODO' comment in the original xscale_analyze_trace().

Outside of xcsale_analyze_trace(), these (related) changes were made:

- Remove pc_ok and current_pc elements from struct xscale_trace.  These elements
  and associated logic are useless clutter because the very first entry placed
  in the trace buffer is always an indirect jump to the address at which
  execution resumed.  This type of trace entry includes the literal address in
  the trace buffer, so the initial address of the trace is immediately
  determined from the trace buffer contents and does not need to be recorded
  when trace is enabled.

- Added num_checkpoints to struct xscale_trace_data, which is necessary in order
  to correctly interpret the checkpoint register contents.

- In xscale_read_trace()
  - Fix potential array out-of-bounds condition.
  - Eliminate partial address entries when parsing trace (can occur in wrap mode).
  - Count and record number of checkpoints in trace.

- Added small, inlined utility function xscale_display_instruction() to help
  make the code more concise and clear.

TODO:
 - Save processor state (arm or thumb) in struct xscale_trace when trace is
   enabled so that trace can be analyzed correctly (currently assumes arm mode).
 - Add element to struct xscale_trace that records (when trace is enabled)
   whether vector table is relocated high (to 0xffff0000) or not, so that a
   branch to an exception vector is traced correctly (curently assumes vectors
   at 0x0).
src/target/xscale.c
src/target/xscale.h

Linking to existing account procedure

If you already have an account and want to add another login method you MUST first sign in with your existing account and then change URL to read https://review.openocd.org/login/?link to get to this page again but this time it'll work for linking. Thank you.

SSH host keys fingerprints

1024 SHA256:YKx8b7u5ZWdcbp7/4AeXNaqElP49m6QrwfXaqQGJAOk gerrit-code-review@openocd.zylin.com (DSA)
384 SHA256:jHIbSQa4REvwCFG4cq5LBlBLxmxSqelQPem/EXIrxjk gerrit-code-review@openocd.org (ECDSA)
521 SHA256:UAOPYkU9Fjtcao0Ul/Rrlnj/OsQvt+pgdYSZ4jOYdgs gerrit-code-review@openocd.org (ECDSA)
256 SHA256:A13M5QlnozFOvTllybRZH6vm7iSt0XLxbA48yfc2yfY gerrit-code-review@openocd.org (ECDSA)
256 SHA256:spYMBqEYoAOtK7yZBrcwE8ZpYt6b68Cfh9yEVetvbXg gerrit-code-review@openocd.org (ED25519)
+--[ED25519 256]--+
|=..              |
|+o..   .         |
|*.o   . .        |
|+B . . .         |
|Bo. = o S        |
|Oo.+ + =         |
|oB=.* = . o      |
| =+=.+   + E     |
|. .=o   . o      |
+----[SHA256]-----+
2048 SHA256:0Onrb7/PHjpo6iVZ7xQX2riKN83FJ3KGU0TvI0TaFG4 gerrit-code-review@openocd.zylin.com (RSA)