Hi,
How are you determining that the trace addresses are mainly in the kernel? Do you have a dump of the decoded trace packets?
If you are getting the trace from the ETB, then the coresight frame formatter will be running, so any trace will have to be first extracted from the frame format before any decode.
Looking at the source code you sent, if you limit the traced region to the code area in your application, then you might expect the trace to contain addresses outside this area as the PTM trace consists of "waypoint" addresses, not individual instructions executed. The decoder determines the executed trace by following the source between waypoint addresses.
A waypoint address will be generated whenever you move out of the specified trace region, so I would guess that each time you call the sqrt() function, an address outside the main program will appear in the trace. Once this function returns you may see a second address output as the trace restarts - this time this should be at the return address for the function.
It may be worthwhile trying to run your data through the trc_pkt_lister test program. To do this you can adapt one of the tests\snapshots to your data. If you look at the TC2 snapshot this has PTM trace in it - the .ini files here could be adapted.
Regards
Mike
On 6 April 2018 at 15:37, Mathieu Poirier mathieu.poirier@linaro.org wrote:
On 5 April 2018 at 10:57, Muhammad Abdul WAHAB muhammadabdul.wahab@centralesupelec.fr wrote:
Hi Mathieu,
Le 05/04/2018 à 17:27, Mathieu Poirier a écrit :
You have a TPIU driver?
Yes, I slightly modified the existing TPIU driver and it worked. Luckily, the TPIU does not require much configuration. I am not enabling the formatter of TPIU because I am tracing only single CPU core. As it is incomplete (no formatter), I did not submitted it as a patch.
How many CPUs on this system? Are you sure the application runs on PTM0? Could it be running on another processor?
I have two CPUs on my system. I made sure that the program runs on the CPU that I am tracing by turning off the second core through sysfs.
I will offer (without looking at your above configuration) that by default the tracers are configured to trace the whole address range. As such can you tell me what you're getting if you enable the tracers without doing any configuration of your own? It could also be that the default configuration is clashing with your new configuration but that's a conversation we can have in an upcoming email once you've answered the above questions.
If I enable trace sink and source components without any configuration of my own, I am getting some trace that consists mainly of kernel code (addresses above 0xc000 0000). For example, the output of dd then hexdump looks like the trace below.
00000000 ab e3 db 0d 72 37 85 80 fe ff 4f 14 d1 f6 81 80 |....r7....O.....| 00000010 0e 77 86 9f 86 24 86 a9 05 8e c5 99 a0 01 c3 d9 |.w...$..........| 00000020 88 00 8e 95 1a 86 f1 bc 0c 86 9f da 08 53 f1 bc |.............S..| 00000030 0c 85 3d d9 da 08 23 cd 99 a0 01 86 69 d9 85 a4 |..=...#.....i...| 00000040 00 f5 f6 23 e9 38 05 df 85 24 9e d5 f5 23 9e bf |...#.8...$...#..| 00000050 36 2d fd 9b a0 01 f1 da 88 00 9e bf 1b 8f 9c a0 |6-..............| 00000060 01 86 b1 f6 a3 00 86 b7 82 20 86 51 86 ff 83 28 |......... .Q...(| 00000070 dd 82 20 e1 a9 29 e3 82 20 c1 c0 20 86 e7 82 20 |.. ..).. .. ... | 00000080 bb f6 23 e1 f5 01 86 b9 ab e3 db 0d 86 cf 89 1c |..#.............| 00000090 fb d3 82 80 08 d1 97 02 e1 f2 db db 0d ff d3 82 |................| 000000a0 80 08 b7 98 02 e9 aa e3 db 0d 9d f9 1a 33 f1 aa |.............3..| 000000b0 23 e7 9e 22 d3 2e 73 89 22 86 72 1b 85 80 fe ff |#.."..s.".r.....| 000000c0 4f 14 d1 f6 81 80 0e 77 86 f5 82 20 e1 81 24 c5 |O......w... ..$.| 000000d0 99 a0 01 c3 d9 88 00 8e 95 1a 86 f1 bc 0c 86 9f |................| 000000e0 da 08 53 f1 bc 0c 85 3d d9 da 08 23 cd 99 a0 01 |..S....=...#....| 000000f0 86 69 ed 81 a4 00 8e a3 02 b1 f2 23 a9 82 24 fd |.i.........#..$.| 00000100 9b a0 01 f1 da 88 00 9e bf 1b 8f 9c a0 01 86 ad |................| 00000110 82 a4 00 b7 82 20 86 51 86 ff 83 28 dd 82 20 e1 |..... .Q...(.. .| 00000120 a9 29 e3 82 20 c1 c0 20 86 e7 82 20 85 03 86 e1 |.).. .. ... ....| 00000130 f5 01 86 9d a2 e2 db 0d 83 2f 2b 83 ab 23 cf 89 |........./+..#..| 00000140 1c 87 d4 82 80 08 d1 97 02 e1 f2 db db 0d 89 d4 |................| 00000150 82 80 08 a5 03 86 c3 9e 02 86 99 1f 8f d4 02 b3 |................| 00000160 94 02 bd 88 e3 db 0d 86 8d 09 ff 89 1c 95 0a 86 |................| 00000170 13 86 13 86 13 86 13 86 13 86 13 86 13 86 13 86 |................| ... and so on.
How can I make sure that there are no conflicts of kernel configuration ?
You will likely have to instrument the code. When tracers are enabled I would look at the final configuration (via sysFS), to make sure what you have there is really what you wrote in the configuration registers.
Best regards, Muhammad
CoreSight mailing list CoreSight@lists.linaro.org https://lists.linaro.org/mailman/listinfo/coresight