Using this feature, you can both run and step, including hitting breakpoints
and watchpoints. You can also view the contents of recorded memory, registers, and
variables at any point in your application's execution. Debugging backwards, can cut
down the time it takes to find a bug from hours to minutes since you do not have to
recreate the same steps that caused a crash, which can be difficult in the case of
non-deterministic bugs.
For errors as simple as an uninitialized or out-of-range array index, or application
crashes caused by null pointers, the application rewind feature can prove extremely
useful, especially since a crash might not even occur in the same source file as the
one with the bug.
Note
Application Rewind is only supported in DS-5 Professional Edition and DS-5
Ultimate Edition.
Application rewind versus conventional debugging techniques
Trace is an extremely effective tool for debugging system issues as it can record a complete
picture of execution and is non-intrusive. Bare-metal or kernel debugging uses trace
for this purpose by recording instructions that are executed on a processor over a
period of time.
However, from the debugger's view, it is not practical to use trace on Linux
applications, because:
- In production systems, trace might not be exposed, so cannot be accessed.
- It can be time-consuming to track an application that migrates between
cores.
- On a multicore SoC, a trace buffer can fill rapidly, limiting the amount of
time available for recording program execution. Also, in situations where a bug
occurs long before the application crash, the trace buffer might not be large
enough to capture the full event.
Classic printf debugging techniques present a different set of challenges. It
is difficult to know how often you need to stage printf statements
and the statement might have a "probe-effect" on your code. Also, rebuilding an
application every time an annotation is added can be time-consuming.
For these reasons, when debugging user-space applications over TCP/IP or USB, a
different approach is required.
How does application rewind work?
Application rewind debug sessions are launched from the debug configurations
panel and can be either controlled from the graphical debugger or the command line
debugger.
Application rewind works in a similar way to standard debugging of Linux
applications using a TCP/IP or USB connection, though instead of using gdbserver, it uses a custom debug agent. This custom
debug agent records a copy-on-write snapshot of the application being debugged,
along with non-deterministic inputs. This allows the debugger to reconstruct a
complete picture of program execution.
Note
Debugging your application using application rewind results in
increased memory consumption on your target and might slow down your application. The
exact impact is dependent on the behavior of your application. Applications that perform
large amounts of I/O are likely to experience increased memory consumption during the
recording process.
Once a bug is recorded, replay is deterministic, with exactly the same behavior
observed with each rewind and play.
PDF version