The DBGPCSR register format is not correct, but the debug tools can calculate the expected PC value and instruction state.
Impact: |
Minor. The debug tools must recognize when to properly calculate the program counter, program counter (PC) for the processor. |
Work-around: |
The debugger tools can find the expected PC value and instruction state by reading the DBGPCSR register. |
Configurations Affected: |
Systems that use one or both ARM processors. |
Device Revision(s) Affected: | All, no plan to fix. Refer to Zynq-7000 Device Advisory Master Answer Record |
The ARM Architecture specifies the DBGPCSR register as:
This field encodes the processor instruction set state, so that the profiling tool can calculate the true instruction address by subtracting the appropriate offset from the value sampled in bits [31:2] of the register.
In Cortex-A9, the DBGPCSR samples the target address of executed branches (but possibly still speculative to data aborts), with the following encodings:
Impact Details
The impact is minor. The implication of this issue is that the debugger tools must not rely on the specified value of DBGPCSR[1:0] or remove any offset from DBGPCSR[31:2] to obtain the expected PC value. Subtracting 4 or 8 from the DBGPCSR[31:2] value would lead to an area of code which is unlikely to have been recently executed or could even not contain any executable code.
The same might be true for Thumb instructions at half-word boundaries, in which case PC[1]=1 but DBGPCSR[1]=0, or ThumbEE instructions at word boundaries, with PC[1]=0 and DBGPCSR[1]=1.
In Cortex-A9, because the DBGPCSR is always a branch target (= start of a basic block to the tool), the debugger should be able to spot many of these cases and attribute the sample to the right basic block.
AR# 47554 | |
---|---|
Date | 08/06/2012 |
Status | Active |
Type | Design Advisory |
Devices |