Hi,
While attempt of profiling of our code using Spectrum Digital XDS 560v2 PRO TRACE and CodeComposer 5.4 we have met a problem. The problem is that for some testcases the profiling results are incorrect - they contain functions that are not called during the test (also some number of function calls and cycles spent looks incosistent).
But the main issue is that the trace records (in TDF file) point to addresses which are resolved both by CCS (and manually using by *.map file) to functions that are never called in that tests, although - these functions are direct neighbours of functions that have been really performed.
I.e. let's imagine we have 3 functions placed one by one in the memory (as map file indicates)
funA() [starts at 0x11831000]
funB() [starts at 0x11832000]
funC() [starts at 0x11833000]
Our test uses only funB() but traces point that subsequent program counter is (i.e.) 0x11831800, 0x11831804, …, 0x11832800, ..
while addresses from 0x11831800 to 0x11831996 belong to never called funA() (!).
For some cases there is a reverse behavior – some traces start at funB region but end up in funC() area, funC() is also for sure not called.
In other words it looks like the addresses of functions in the map/out file are shifted in comparison to real code location in the memory or that the debugger somehow shifts the address of program counter.
This obviously leads to incorrect profiling results as there are more functions than really called, cycle distribution is not reliable etc.
For the analysed incorrect address vs map cases we observed the that the ‘offset’ of map in comparison to trace results is plus 64B or minus 64B. The issue is present for both Faraday and Nyquist (CGT 7.3.8, builds made from scratch of course).
One curious fact is that for the same testcases with a minor code change the trace/profiling results looks perfect – there is no not called function, the cycles, the call numbers looks healthy…
Have you met with similar case ?
Thank you in advance for your help!
br,
Olgierd