C.1. About tracing dynamically-loaded code

When a debugger is debugging a system, it communicates mainly in terms of accesses to addresses in memory or virtual memory. It translates between these addresses and the locations in the code images loaded on the system. This means that the debugger can present a symbolic or source-level view of the code running on the system.

In a simple statically-linked and loaded system, a single image is run to describe the mapping of target addresses as image locations. To perform debugging, the debugger requires only the name of the code image. However, many systems, including operating systems such as Windows® CE, Linux®, or Symbian OS™, load part or all of their software dynamically. This can have several effects:

To debug systems like these, the debugger must be able to examine the target, to determine what images are loaded and from where they are loaded.

The problem is more complex when using trace, because trace data is historical information. In any embedded trace solution, the trace decompression software of the debugger requires an image of the code that was executed, otherwise it cannot decode the trace.

The PFT protocol conserves data bandwidth by generating only the minimum of trace information, and compresses the instruction addresses it outputs. This means that, given a compressed address issued by the trace port, the debugger software must be able to know what instructions are at and around that point. This enables the debugger to infer the target address of direct branches, for example B and BL instructions in code in ARM state. This is difficult with, for example, virtual memory and software paging, because the debugger is unlikely to know where the code is executed from.

To resolve this problem, PTM uses Context IDs. These require both software and hardware support. See:

Copyright © 1999-2002, 2004-2008, 2011 ARM. All rights reserved.ARM IHI 0035B