On 7 August 2017 at 21:25, Chunyan Zhang zhang.chunyan@linaro.org wrote:

Hello Thierry,

It sounds that we have a similiar requirement, I'd like to talk a bit the method that I have been trying to decode traces with OpenCSD and perf tools. I learned that method from Leo Yan (cc'ed) who mentioned that in the patch-set [1], and he suggested me to replace the ETM raw trace in perf.data with traces we could get via sysfs and 'dd' command, and then we can use perf script to decode trace which we got via sysfs and dd command.

First of all, I downloaded the latest OpenCSD [2] and perf-with-opencsd [3], compiled them according to the directions provided by HOWTO.md, and then:

1. Using the perf tool compiled from [3], I got the perf.data on the

target (I was using Whale2 [4]): # perf record -e cs_etm/@10003000.etb/ --per-thread uname

2. On the target, collected ETM traces with sysfs command and used

'dd' to dump the trace data to a binary file: # echo 1 > /sys/bus/coresight/devices/10003000.etb/enable_sink # echo 1 > /sys/bus/coresight/devices/11440000.etm/enable_source # dd if=/dev/10003000.etb of=/cstrace.bin

and then copy the binary file to PC.

3. On PC, fill the binary traces into perf.data to replace the

original trace section in perf.data: # dd if=./perf_whale2.data of=./perf_comp_0807.data bs=1 count=1496 # dd if=./cstrace_0807-v4.9.bin of=./perf_comp_0807.data bs=1 count=32768 seek=1496 # dd if=./perf_whale2.data of=./perf_comp_0807.data bs=1 count=2804 seek=34264 skip=34264

This is an example for Whale2 case, you must've noticed there're a few numbers (i.e. 1496, 32768, 2804) which are the size of header, trace binary, and tail of perf.data. I would suggest to use 'perf report --dump' to know these values.

For example, in whale2 case, I got the following data by 'perf report --dump':

[snip]

0x5a8 [0x30]: PERF_RECORD_AUXTRACE size: 0x8000 offset: 0 ref: 0x1eeb385f3231f044 idx: 0 tid: 516 cpu: -1

. ... CoreSight ETM Trace data: size 32768 bytes 38: id[14] I_NOT_SYNC : I Stream not synchronised

[snip]

Please notice the sentence 'CoreSight ETM Trace data: size 32768 bytes' and '0x5a8 [0x30]' above it.

From this we can know the header size is 0x5a8 + 0x30 = 0x5d8 (i.e.

1496 dec), trace binary is 32768, then it's easy to know the size of perf.data tail since we know the total size of perf.data.

Hope that I have've made this clear :)

Regards, Chunyan

4. Use perf script + OpenCSD to decode the traces:

# perf script -v -F cpu,event,ip,sym,symoff --kallsyms System.map

-i perf_comp_0807.data -k vmlinux

The decoded trace would like:
   [000]          instructions:  ffffff8008088e68 do_signal+0x4c0
   [000]          instructions:  ffffff8008088e98 do_signal+0x4f0
   [000]          instructions:  ffffff8008088ed4 do_signal+0x52c
   [000]          instructions:  ffffff8008088e48 do_signal+0x4a0
   [000]          instructions:  ffffff8008088ef8 sys_rt_sigreturn+0x8
   [000]          instructions:  ffffff8008088f54 sys_rt_sigreturn+0x64
   [000]          instructions:  ffffff8008088f6c sys_rt_sigreturn+0x7c
   [000]          instructions:  ffffff800831e574 flags_string+0x34

Side note:

1. I'd suggest to disable CONFIG_CPU_IDLE (especially when you're

using the v4.12 and previous version of kernel) 2) Please double check if the sink is enabled after setting the source device enabled. 3) Using the older version of kernels - say v4.9 and the previous ones

• you may get nothing if you set the source disabled before using dd

command to dump sink device to a binary file.

I've shared the trace data and symbol files here [5].

I hope it can be helpful, if you have any questions about this, please let me know.

Thanks, Chunyan

[1] https://lkml.org/lkml/2017/6/3/146 [2] https://github.com/Linaro/OpenCSD/tree/v0.7 [3] https://github.com/Linaro/OpenCSD/tree/perf-opencsd-4.12 [4] http://elixir.free-electrons.com/linux/v4.13-rc1/source/arch/arm64/boot/dts/... [5] http://people.linaro.org/~zhang.chunyan/whale2-uname-0807-lsk/

On 4 August 2017 at 21:33, Thierry Laviron Thierry.Laviron@arm.com wrote:

...

Hi Mike,

I am trying to decompress trace data produced using the sysfs interface on my Juno r2 board, get back to the assembly code that was executed.

I have read through This Post on the Linaro wiki, which explains how to do this with DS-5, which I do not have installed on the Juno.

I would like to know if there is a way to use the OpenCSD library, or a part of it, that will allow me to do this.

With your advice in your previous email, I have been able to use the ‘trc_pkt_lister’ executable, to list trace packets in a human-readable form.

I saw in the documentation for the snapshot format that there is a [dump] section for files describing a core, which might describe an area of memory containing the program executed by the core.

Can this information be used by ‘trc_pkt_lister’ ? I tried using it on the provided ‘juno_r1_1’ test snapshot, with ‘-decode’ or with ‘-decode-only’, but these do not appear to be what I am looking for.

Basically, Assuming I have the compiled ELF binary and the associated trace (either in text form using the output of trc_pck_lister, or using the openCSD API), which only gives me virtual addresses executed by the program and indications about taken branches, how do I know where is my program relocated?

This is the part that I am missing, I need to know how the addresses I am seeing in the trace relate to the compiled program.

I would welcome any advice on the subject.

Best regards,

Thierry

IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.

---

CoreSight mailing list CoreSight@lists.linaro.org https://lists.linaro.org/mailman/listinfo/coresight