Hi Chunyan.
There is plenty of documentation for DS-5, but the path from snapshot to trace dump is not obvious so I will give you a few pointers.
1) first you need to create a DS-5 configuration that will load your snapshot.
a) On the menu choose "run->debug configurations" which will open the debug configurations dialog. b) Click the "new configuration button" - leftmost button above the left pane to create a new configuration. c) In the Name: edit box type a new name for this configuration d) on the "connection" tab in the right hand pane navigate to Generic->Snapshot->View Snapshot->ViewSnapshot. e) below this browse for the snapshot.ini file you want to use in the configuration by clicking the File... button and select a file. See attached ds-5-debug-config.png for picture of above dialog.
f) On the "debugger" tab, select the "connect only" radio button in the Run Control area. Hit "Apply" and "close" and you new "Snapshot connection" should be visible in the "debug Control" tab in DS-5. Right click, hit connect and DS-5 should load the snapshot.
2) Creating a dump text. a) Now select a core in the left panel to see trace for that core. b) Hit the export trace button to open the export trace report dialog. Look at export-trace.png
From here just choose what you want to dump and hit OK
Regards
Mike
On 4 September 2017 at 09:29, Chunyan Zhang zhang.chunyan@linaro.org wrote:
Hi Mike,
On 16 August 2017 at 00:07, Mike Leach mike.leach@linaro.org wrote:
Hi Maryem,
The output you have above is a mix of raw trace packets and the decoded generic output packets. i.e. I_ATOM_F3 is a raw trace packet from the ETMv4 protocol, OCSD_GEN_TRC_ELEM_ADDR_NACC( 0x40c4ec ) is the generic output packet from the decoder after processing a number of raw trace packets. In this case the OCSD_GEN_TRC_ELEM_ADDR_NACC( 0x40c4ec ) packet indicates that the decoder does not have the memory image for address 0x40c4ec and therefore cannot decode correctly.
If you are not using perf to capture trace data then I assume you are using some other custom method. e.g. sysfs scripts / programs. Once you have captured a buffer full of data, if you are not using a debugger such as DS-5 then it will be necessary to write a custom
I used sysfs to capture trace data, and have decoded them with 'trc_pkt_lister' which compiled from opencsd (the .ini files under snapshots were modified from TC2's, since I was decoding etmv3 traces).
From what you mentioned here, I guess DS-5 can decode the data further to make it readable in assemble language? I hope that the traces can look like this: https://github.com/Linaro/OpenCSD/blob/master/decoder/tests/snapshots/TC2/ds...
Could you tell me what should I do? Is there some documentation introducing how to operate DS-5 to get this kind of decoded data? I have a DStream, but haven't used it ever :)
Thanks, Chunyan
program or script to do the following:- a) using the OpenCSD library, create a decoder instance and use the API to pass in the ETM settings used during the trace capture session. b) further use the API to pass in any memory images of the traced code / kernel memory you wish to decode. c) Pass the trace data through the decoder instance and process the output generic packets that represent executed instruction ranges by passing them to a disassembly tool/library to create the output you require.
Best Regards
Mike
On 15 August 2017 at 15:56, Mathieu Poirier mathieu.poirier@linaro.org wrote:
Good morning Maryem,
I am enlisting Mike's help on this one. When looking for support on CoreSight I suggest you CC the mailing list - there is a lot of knowledgeable people on there that can help you.
Mathieu
On 11 August 2017 at 08:57, Maryem Ayadi maryem.ayady@gmail.com wrote:
Hi mathieu,
I am working with the Opencsd library under linux in order to collect and decode the trace. I am using the Snapshots directory and I already decoded the trace packets from ETB_0 using ETM and captured from juno_r1_1 using the following command: ./tests/bin/linux64/dbg/trc_pkt_lister -ss_dir tests/snapshots/juno_r1_1/ -decode -src_name ETB_0 . This is an extract of the generic output packets:
Idx:65507; ID:15; OCSD_GEN_TRC_ELEM_ADDR_NACC( 0x40c5dc ) Idx:65508; ID:15; [0x95 0x3b ]; I_ADDR_S_IS0 : Address, Short, IS0.; Addr=0x000000000040C4EC ~[0xEC] Idx:65510; ID:15; [0xfe ]; I_ATOM_F3 : Atom format 3.; NEE Idx:65510; ID:15; OCSD_GEN_TRC_ELEM_ADDR_NACC( 0x40c4ec ) Idx:65475; ID:10; OCSD_GEN_TRC_ELEM_EO_TRACE()
Now I want to generate trace data captured with ETM and coded in assembly language. Is that possible without using any debugger tool such as ARM's DS-5 debugger tool ? It would be helpful to send me any steps I should follow.
Best regards, Maryem Ayadi
-- Mike Leach Principal Engineer, ARM Ltd. Blackburn Design Centre. UK _______________________________________________ CoreSight mailing list CoreSight@lists.linaro.org https://lists.linaro.org/mailman/listinfo/coresight
Hi Mike,
Thanks for the detailed instructions.
On 4 September 2017 at 23:13, Mike Leach mike.leach@linaro.org wrote:
Hi Chunyan.
There is plenty of documentation for DS-5, but the path from snapshot to trace dump is not obvious so I will give you a few pointers.
- first you need to create a DS-5 configuration that will load your snapshot.
a) On the menu choose "run->debug configurations" which will open the debug configurations dialog. b) Click the "new configuration button" - leftmost button above the left pane to create a new configuration. c) In the Name: edit box type a new name for this configuration d) on the "connection" tab in the right hand pane navigate to Generic->Snapshot->View Snapshot->ViewSnapshot. e) below this browse for the snapshot.ini file you want to use in the configuration by clicking the File... button and select a file. See attached ds-5-debug-config.png for picture of above dialog.
f) On the "debugger" tab, select the "connect only" radio button in the Run Control area. Hit "Apply" and "close" and you new "Snapshot connection" should be visible in the "debug Control" tab in DS-5. Right click, hit connect and DS-5 should load the snapshot.
We have to ensure the target is connecting with DStream when hit connect on DS-5, right?
Is there any way for offline decoding snapshot of raw trace [1] further which I mean decoded by 'trc_pkt_lister'. Since the decoded traces [1] are still not easy to be used for understanding what the system was doing.
Or how you would suggest us to use this kind of traces decoded by 'trc_pkt_lister' to understand the behavior of CPU core?
Thanks, Chunyan
[1] http://people.linaro.org/~zhang.chunyan/opencsd_decoder/tests/snapshots/shar...
- Creating a dump text.
a) Now select a core in the left panel to see trace for that core. b) Hit the export trace button to open the export trace report dialog. Look at export-trace.png From here just choose what you want to dump and hit OK
Regards
Mike
On 4 September 2017 at 09:29, Chunyan Zhang zhang.chunyan@linaro.org wrote:
Hi Mike,
On 16 August 2017 at 00:07, Mike Leach mike.leach@linaro.org wrote:
Hi Maryem,
The output you have above is a mix of raw trace packets and the decoded generic output packets. i.e. I_ATOM_F3 is a raw trace packet from the ETMv4 protocol, OCSD_GEN_TRC_ELEM_ADDR_NACC( 0x40c4ec ) is the generic output packet from the decoder after processing a number of raw trace packets. In this case the OCSD_GEN_TRC_ELEM_ADDR_NACC( 0x40c4ec ) packet indicates that the decoder does not have the memory image for address 0x40c4ec and therefore cannot decode correctly.
If you are not using perf to capture trace data then I assume you are using some other custom method. e.g. sysfs scripts / programs. Once you have captured a buffer full of data, if you are not using a debugger such as DS-5 then it will be necessary to write a custom
I used sysfs to capture trace data, and have decoded them with 'trc_pkt_lister' which compiled from opencsd (the .ini files under snapshots were modified from TC2's, since I was decoding etmv3 traces).
From what you mentioned here, I guess DS-5 can decode the data further to make it readable in assemble language? I hope that the traces can look like this: https://github.com/Linaro/OpenCSD/blob/master/decoder/tests/snapshots/TC2/ds...
Could you tell me what should I do? Is there some documentation introducing how to operate DS-5 to get this kind of decoded data? I have a DStream, but haven't used it ever :)
Thanks, Chunyan
program or script to do the following:- a) using the OpenCSD library, create a decoder instance and use the API to pass in the ETM settings used during the trace capture session. b) further use the API to pass in any memory images of the traced code / kernel memory you wish to decode. c) Pass the trace data through the decoder instance and process the output generic packets that represent executed instruction ranges by passing them to a disassembly tool/library to create the output you require.
Best Regards
Mike
On 15 August 2017 at 15:56, Mathieu Poirier mathieu.poirier@linaro.org wrote:
Good morning Maryem,
I am enlisting Mike's help on this one. When looking for support on CoreSight I suggest you CC the mailing list - there is a lot of knowledgeable people on there that can help you.
Mathieu
On 11 August 2017 at 08:57, Maryem Ayadi maryem.ayady@gmail.com wrote:
Hi mathieu,
I am working with the Opencsd library under linux in order to collect and decode the trace. I am using the Snapshots directory and I already decoded the trace packets from ETB_0 using ETM and captured from juno_r1_1 using the following command: ./tests/bin/linux64/dbg/trc_pkt_lister -ss_dir tests/snapshots/juno_r1_1/ -decode -src_name ETB_0 . This is an extract of the generic output packets:
Idx:65507; ID:15; OCSD_GEN_TRC_ELEM_ADDR_NACC( 0x40c5dc ) Idx:65508; ID:15; [0x95 0x3b ]; I_ADDR_S_IS0 : Address, Short, IS0.; Addr=0x000000000040C4EC ~[0xEC] Idx:65510; ID:15; [0xfe ]; I_ATOM_F3 : Atom format 3.; NEE Idx:65510; ID:15; OCSD_GEN_TRC_ELEM_ADDR_NACC( 0x40c4ec ) Idx:65475; ID:10; OCSD_GEN_TRC_ELEM_EO_TRACE()
Now I want to generate trace data captured with ETM and coded in assembly language. Is that possible without using any debugger tool such as ARM's DS-5 debugger tool ? It would be helpful to send me any steps I should follow.
Best regards, Maryem Ayadi
-- Mike Leach Principal Engineer, ARM Ltd. Blackburn Design Centre. UK _______________________________________________ CoreSight mailing list CoreSight@lists.linaro.org https://lists.linaro.org/mailman/listinfo/coresight
-- Mike Leach Principal Engineer, ARM Ltd. Blackburn Design Centre. UK
Hi Chunyan,
On Tue, 5 Sep 2017 at 04:19, Chunyan Zhang zhang.chunyan@linaro.org wrote:
Hi Mike,
Thanks for the detailed instructions.
On 4 September 2017 at 23:13, Mike Leach mike.leach@linaro.org wrote:
Hi Chunyan.
There is plenty of documentation for DS-5, but the path from snapshot to trace dump is not obvious so I will give you a few pointers.
- first you need to create a DS-5 configuration that will load your
snapshot.
a) On the menu choose "run->debug configurations" which will open the debug configurations dialog. b) Click the "new configuration button" - leftmost button above the left pane to create a new configuration. c) In the Name: edit box type a new name for this configuration d) on the "connection" tab in the right hand pane navigate to Generic->Snapshot->View Snapshot->ViewSnapshot. e) below this browse for the snapshot.ini file you want to use in the configuration by clicking the File... button and select a file. See attached ds-5-debug-config.png for picture of above dialog.
f) On the "debugger" tab, select the "connect only" radio button in the Run Control area. Hit "Apply" and "close" and you new "Snapshot connection" should be visible in the "debug Control" tab in DS-5. Right click, hit connect and DS-5 should load the snapshot.
We have to ensure the target is connecting with DStream when hit connect on DS-5, right?
No - snapshot support in DS5 is fully offline.
But you do need to have the memory images of the applications you traced as part of the snapshot to make decode work correctly.
Is there any way for offline decoding snapshot of raw trace [1] further which I mean decoded by 'trc_pkt_lister'. Since the decoded traces [1] are still not easy to be used for understanding what the system was doing.
t rc_pkt_lister is a test tool for the library so does not have advanced disassembly capability.
You can add the -decode or -decode-only option to the command line to get the trace packets decoded into executed instruction ranges and obtain output similar to that below:-
Idx:348; ID:12; [0xdd 0xf9 0xf5 0xdf 0xfc 0xf9 0xdc ]; I_NOT_SYNC : I Stream not synchronised Idx:356; ID:12; [0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x80 ]; I_ASYNC : Alignment Synchronisation. Idx:369; ID:12; [0x01 0x01 0x00 ]; I_TRACE_INFO : Trace Info.; INFO=0x0 Idx:372; ID:12; [0xf7 ]; I_ATOM_F1 : Atom format 1.; E Idx:373; ID:12; [0x85 0x22 0x12 0x4d 0x00 0x00 0x00 0x00 0x00 0x30 ]; I_ADDR_CTXT_L_64IS0 : Address & Context, Long, 64 bit, IS0.; Addr=0x00000000004D2488; Ctxt: AArch64,EL0, NS; Idx:384; ID:12; [0xf7 ]; I_ATOM_F1 : Atom format 1.; E Idx:373; ID:12; OCSD_GEN_TRC_ELEM_PE_CONTEXT((ISA=Unk) EL0N; 64-bit; ) Idx:384; ID:12; OCSD_GEN_TRC_ELEM_INSTR_RANGE(exec range=0x4d2488:[0x4d2494] (ISA=A64) E iBR A64:ret ) Idx:385; ID:12; [0x9d 0x48 0x5f 0x4d 0x00 0x00 0x00 0x00 0x00 ]; I_ADDR_L_64IS0 : Address, Long, 64 bit, IS0.; Addr=0x00000000004DBF20; Idx:394; ID:12; [0xde ]; I_ATOM_F4 : Atom format 4.; NENE Idx:394; ID:12; OCSD_GEN_TRC_ELEM_INSTR_RANGE(exec range=0x4dbf20:[0x4dbf24] (ISA=A64) N BR ) Idx:394; ID:12; OCSD_GEN_TRC_ELEM_INSTR_RANGE(exec range=0x4dbf24:[0x4dbf2c] (ISA=A64) E BR b+link ) Idx:394; ID:12; OCSD_GEN_TRC_ELEM_INSTR_RANGE(exec range=0x4d1d88:[0x4d1db4] (ISA=A64) N BR ) Idx:394; ID:12; OCSD_GEN_TRC_ELEM_INSTR_RANGE(exec range=0x4d1db4:[0x4d1dbc] (ISA=A64) E BR ) Idx:395; ID:12; [0xdb ]; I_ATOM_F2 : Atom format 2.; EE Idx:395; ID:12; OCSD_GEN_TRC_ELEM_INSTR_RANGE(exec range=0x4d1dd8:[0x4d1df0] (ISA=A64) E BR ) Idx:395; ID:12; OCSD_GEN_TRC_ELEM_INSTR_RANGE(exec range=0x4d1dbc:[0x4d1dd8] (ISA=A64) E iBR A64:ret ) Idx:396; ID:12; [0x95 0x4b ]; I_ADDR_S_IS0 : Address, Short, IS0.; Addr=0x00000000004DBF2C ~[0x12C] Idx:398; ID:12; [0xe0 ]; I_ATOM_F6 : Atom format 6.; EEEN Idx:398; ID:12; OCSD_GEN_TRC_ELEM_INSTR_RANGE(exec range=0x4dbf2c:[0x4dbf38] (ISA=A64) E BR ) Idx:398; ID:12; OCSD_GEN_TRC_ELEM_INSTR_RANGE(exec range=0x4dc0cc:[0x4dc0d8] (ISA=A64) E BR ) Idx:398; ID:12; OCSD_GEN_TRC_ELEM_INSTR_RANGE(exec range=0x4dbf38:[0x4dbf44] (ISA=A64) E BR b+link ) Idx:398; ID:12; OCSD_GEN_TRC_ELEM_INSTR_RANGE(exec range=0x4cf4b0:[0x4cf4d0] (ISA=A64) N BR ) Idx:400; ID:12; [0xdb ]; I_ATOM_F2 : Atom format 2.; EE Idx:400; ID:12; OCSD_GEN_TRC_ELEM_INSTR_RANGE(exec range=0x4cf4d0:[0x4cf500] (ISA=A64) E BR ) Idx:400; ID:12; OCSD_GEN_TRC_ELEM_INSTR_RANGE(exec range=0x4cf5a8:[0x4cf5bc] (ISA=A64) E iBR ) Idx:401; ID:12; [0x95 0x88 0x7b ]; I_ADDR_S_IS0 : Address, Short, IS0.; Addr=0x00000000004CF620 ~[0xF620] Idx:404; ID:12; [0xdc ]; I_ATOM_F4 : Atom format 4.; NEEE Idx:404; ID:12; OCSD_GEN_TRC_ELEM_INSTR_RANGE(exec range=0x4cf620:[0x4cf62c] (ISA=A64) N BR ) Idx:404; ID:12; OCSD_GEN_TRC_ELEM_INSTR_RANGE(exec range=0x4cf62c:[0x4cf63c] (ISA=A64) E BR ) Idx:404; ID:12; OCSD_GEN_TRC_ELEM_INSTR_RANGE(exec range=0x4cf7bc:[0x4cf7d8] (ISA=A64) E BR ) Idx:404; ID:12; OCSD_GEN_TRC_ELEM_INSTR_RANGE(exec range=0x4cf588:[0x4cf5a8] (ISA=A64) E iBR A64:ret ) Idx:405; ID:12; [0x95 0xd1 0xdf ]; I_ADDR_S_IS0 : Address, Short, IS0.; Addr=0x00000000004DBF44 ~[0x1BF44] Idx:408; ID:12; [0xe0 ]; I_ATOM_F6 : Atom format 6.; EEEN Idx:408; ID:12; OCSD_GEN_TRC_ELEM_INSTR_RANGE(exec range=0x4dbf44:[0x4dbf6c] (ISA=A64) E BR )
The OCSD_GEN_TRC_ELEM_INSTR_RANGE packets are instruction executed ranges, address inclusive to exclusive. The perf tool uses this decoder packet output to produce disassembly using perf script and passing the range to the gcc objdump utility for disassembly.
If memory images for the addresses are not included in your snapshot then you will see OCSD_GEN_TRC_ELEM_NACC(<address>) indicating that the decoder could not access the address present in the trace data.
Look at decoder/snapshots/trace_cov_a15 for an example of a snapshot that has multiple memory images for the application executed.
Or how you would suggest us to use this kind of traces decoded by 'trc_pkt_lister' to understand the behavior of CPU core?
To get further processing of the trace you will need to either feed the snapshot into DS-5, or write your own utility to drive the decoder library and disassemble the decoded output.
Regards
Mike
Thanks, Chunyan
[1] http://people.linaro.org/~zhang.chunyan/opencsd_decoder/ tests/snapshots/sharkl2/decode_result-etm0.txt
- Creating a dump text.
a) Now select a core in the left panel to see trace for that core. b) Hit the export trace button to open the export trace report dialog. Look at export-trace.png From here just choose what you want to dump and hit OK
Regards
Mike
On 4 September 2017 at 09:29, Chunyan Zhang zhang.chunyan@linaro.org
wrote:
Hi Mike,
On 16 August 2017 at 00:07, Mike Leach mike.leach@linaro.org wrote:
Hi Maryem,
The output you have above is a mix of raw trace packets and the decoded generic output packets. i.e. I_ATOM_F3 is a raw trace packet from the ETMv4 protocol, OCSD_GEN_TRC_ELEM_ADDR_NACC( 0x40c4ec ) is the generic output packet from the decoder after processing a number of raw trace packets. In this case the OCSD_GEN_TRC_ELEM_ADDR_NACC( 0x40c4ec ) packet indicates that the decoder does not have the memory image for address 0x40c4ec and therefore cannot decode correctly.
If you are not using perf to capture trace data then I assume you are using some other custom method. e.g. sysfs scripts / programs. Once you have captured a buffer full of data, if you are not using a debugger such as DS-5 then it will be necessary to write a custom
I used sysfs to capture trace data, and have decoded them with 'trc_pkt_lister' which compiled from opencsd (the .ini files under snapshots were modified from TC2's, since I was decoding etmv3 traces).
From what you mentioned here, I guess DS-5 can decode the data further to make it readable in assemble language? I hope that the traces can look like this: https://github.com/Linaro/OpenCSD/blob/master/decoder/
tests/snapshots/TC2/ds5-dumps/etmv3_0x10.txt
Could you tell me what should I do? Is there some documentation introducing how to operate DS-5 to get this kind of decoded data? I have a DStream, but haven't used it ever :)
Thanks, Chunyan
program or script to do the following:- a) using the OpenCSD library, create a decoder instance and use the API to pass in the ETM settings used during the trace capture session. b) further use the API to pass in any memory images of the traced code / kernel memory you wish to decode. c) Pass the trace data through the decoder instance and process the output generic packets that represent executed instruction ranges by passing them to a disassembly tool/library to create the output you require.
Best Regards
Mike
On 15 August 2017 at 15:56, Mathieu Poirier <
mathieu.poirier@linaro.org> wrote:
Good morning Maryem,
I am enlisting Mike's help on this one. When looking for support on CoreSight I suggest you CC the mailing list - there is a lot of knowledgeable people on there that can help you.
Mathieu
On 11 August 2017 at 08:57, Maryem Ayadi maryem.ayady@gmail.com
wrote:
Hi mathieu,
I am working with the Opencsd library under linux in order to
collect and
decode the trace. I am using the Snapshots directory and I already decoded the trace
packets
from ETB_0 using ETM and captured from juno_r1_1 using the following command: ./tests/bin/linux64/dbg/trc_pkt_lister -ss_dir tests/snapshots/juno_r1_1/ -decode -src_name ETB_0 . This is an
extract of
the generic output packets:
Idx:65507; ID:15; OCSD_GEN_TRC_ELEM_ADDR_NACC( 0x40c5dc ) Idx:65508; ID:15; [0x95 0x3b ]; I_ADDR_S_IS0 : Address, Short,
IS0.;
Addr=0x000000000040C4EC ~[0xEC] Idx:65510; ID:15; [0xfe ]; I_ATOM_F3 : Atom format 3.; NEE Idx:65510; ID:15; OCSD_GEN_TRC_ELEM_ADDR_NACC( 0x40c4ec ) Idx:65475; ID:10; OCSD_GEN_TRC_ELEM_EO_TRACE()
Now I want to generate trace data captured with ETM and coded in
assembly
language. Is that possible without using any debugger tool such as
ARM's
DS-5 debugger tool ? It would be helpful to send me any steps I should follow.
Best regards, Maryem Ayadi
-- Mike Leach Principal Engineer, ARM Ltd. Blackburn Design Centre. UK _______________________________________________ CoreSight mailing list CoreSight@lists.linaro.org https://lists.linaro.org/mailman/listinfo/coresight
-- Mike Leach Principal Engineer, ARM Ltd. Blackburn Design Centre. UK
Hi Mike,
On 5 September 2017 at 16:46, Mike Leach mike.leach@linaro.org wrote:
Hi Chunyan,
On Tue, 5 Sep 2017 at 04:19, Chunyan Zhang zhang.chunyan@linaro.org wrote:
Hi Mike,
Thanks for the detailed instructions.
On 4 September 2017 at 23:13, Mike Leach mike.leach@linaro.org wrote:
Hi Chunyan.
There is plenty of documentation for DS-5, but the path from snapshot to trace dump is not obvious so I will give you a few pointers.
- first you need to create a DS-5 configuration that will load your
snapshot.
a) On the menu choose "run->debug configurations" which will open the debug configurations dialog. b) Click the "new configuration button" - leftmost button above the left pane to create a new configuration. c) In the Name: edit box type a new name for this configuration d) on the "connection" tab in the right hand pane navigate to Generic->Snapshot->View Snapshot->ViewSnapshot. e) below this browse for the snapshot.ini file you want to use in the configuration by clicking the File... button and select a file. See attached ds-5-debug-config.png for picture of above dialog.
f) On the "debugger" tab, select the "connect only" radio button in the Run Control area. Hit "Apply" and "close" and you new "Snapshot connection" should be visible in the "debug Control" tab in DS-5. Right click, hit connect and DS-5 should load the snapshot.
We have to ensure the target is connecting with DStream when hit connect on DS-5, right?
No - snapshot support in DS5 is fully offline.
That's great. I will try again.
But you do need to have the memory images of the applications you traced as part of the snapshot to make decode work correctly.
Is there any way for offline decoding snapshot of raw trace [1] further which I mean decoded by 'trc_pkt_lister'. Since the decoded traces [1] are still not easy to be used for understanding what the system was doing.
t rc_pkt_lister is a test tool for the library so does not have advanced disassembly capability.
You can add the -decode or -decode-only option to the command line to get the trace packets decoded into executed instruction ranges and obtain output similar to that below:-
Idx:348; ID:12; [0xdd 0xf9 0xf5 0xdf 0xfc 0xf9 0xdc ]; I_NOT_SYNC : I Stream not synchronised Idx:356; ID:12; [0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x80 ]; I_ASYNC : Alignment Synchronisation. Idx:369; ID:12; [0x01 0x01 0x00 ]; I_TRACE_INFO : Trace Info.; INFO=0x0 Idx:372; ID:12; [0xf7 ]; I_ATOM_F1 : Atom format 1.; E Idx:373; ID:12; [0x85 0x22 0x12 0x4d 0x00 0x00 0x00 0x00 0x00 0x30 ]; I_ADDR_CTXT_L_64IS0 : Address & Context, Long, 64 bit, IS0.; Addr=0x00000000004D2488; Ctxt: AArch64,EL0, NS; Idx:384; ID:12; [0xf7 ]; I_ATOM_F1 : Atom format 1.; E Idx:373; ID:12; OCSD_GEN_TRC_ELEM_PE_CONTEXT((ISA=Unk) EL0N; 64-bit; ) Idx:384; ID:12; OCSD_GEN_TRC_ELEM_INSTR_RANGE(exec range=0x4d2488:[0x4d2494] (ISA=A64) E iBR A64:ret ) Idx:385; ID:12; [0x9d 0x48 0x5f 0x4d 0x00 0x00 0x00 0x00 0x00 ]; I_ADDR_L_64IS0 : Address, Long, 64 bit, IS0.; Addr=0x00000000004DBF20; Idx:394; ID:12; [0xde ]; I_ATOM_F4 : Atom format 4.; NENE Idx:394; ID:12; OCSD_GEN_TRC_ELEM_INSTR_RANGE(exec range=0x4dbf20:[0x4dbf24] (ISA=A64) N BR ) Idx:394; ID:12; OCSD_GEN_TRC_ELEM_INSTR_RANGE(exec range=0x4dbf24:[0x4dbf2c] (ISA=A64) E BR b+link ) Idx:394; ID:12; OCSD_GEN_TRC_ELEM_INSTR_RANGE(exec range=0x4d1d88:[0x4d1db4] (ISA=A64) N BR ) Idx:394; ID:12; OCSD_GEN_TRC_ELEM_INSTR_RANGE(exec range=0x4d1db4:[0x4d1dbc] (ISA=A64) E BR ) Idx:395; ID:12; [0xdb ]; I_ATOM_F2 : Atom format 2.; EE Idx:395; ID:12; OCSD_GEN_TRC_ELEM_INSTR_RANGE(exec range=0x4d1dd8:[0x4d1df0] (ISA=A64) E BR ) Idx:395; ID:12; OCSD_GEN_TRC_ELEM_INSTR_RANGE(exec range=0x4d1dbc:[0x4d1dd8] (ISA=A64) E iBR A64:ret ) Idx:396; ID:12; [0x95 0x4b ]; I_ADDR_S_IS0 : Address, Short, IS0.; Addr=0x00000000004DBF2C ~[0x12C] Idx:398; ID:12; [0xe0 ]; I_ATOM_F6 : Atom format 6.; EEEN Idx:398; ID:12; OCSD_GEN_TRC_ELEM_INSTR_RANGE(exec range=0x4dbf2c:[0x4dbf38] (ISA=A64) E BR ) Idx:398; ID:12; OCSD_GEN_TRC_ELEM_INSTR_RANGE(exec range=0x4dc0cc:[0x4dc0d8] (ISA=A64) E BR ) Idx:398; ID:12; OCSD_GEN_TRC_ELEM_INSTR_RANGE(exec range=0x4dbf38:[0x4dbf44] (ISA=A64) E BR b+link ) Idx:398; ID:12; OCSD_GEN_TRC_ELEM_INSTR_RANGE(exec range=0x4cf4b0:[0x4cf4d0] (ISA=A64) N BR ) Idx:400; ID:12; [0xdb ]; I_ATOM_F2 : Atom format 2.; EE Idx:400; ID:12; OCSD_GEN_TRC_ELEM_INSTR_RANGE(exec range=0x4cf4d0:[0x4cf500] (ISA=A64) E BR ) Idx:400; ID:12; OCSD_GEN_TRC_ELEM_INSTR_RANGE(exec range=0x4cf5a8:[0x4cf5bc] (ISA=A64) E iBR ) Idx:401; ID:12; [0x95 0x88 0x7b ]; I_ADDR_S_IS0 : Address, Short, IS0.; Addr=0x00000000004CF620 ~[0xF620] Idx:404; ID:12; [0xdc ]; I_ATOM_F4 : Atom format 4.; NEEE Idx:404; ID:12; OCSD_GEN_TRC_ELEM_INSTR_RANGE(exec range=0x4cf620:[0x4cf62c] (ISA=A64) N BR ) Idx:404; ID:12; OCSD_GEN_TRC_ELEM_INSTR_RANGE(exec range=0x4cf62c:[0x4cf63c] (ISA=A64) E BR ) Idx:404; ID:12; OCSD_GEN_TRC_ELEM_INSTR_RANGE(exec range=0x4cf7bc:[0x4cf7d8] (ISA=A64) E BR ) Idx:404; ID:12; OCSD_GEN_TRC_ELEM_INSTR_RANGE(exec range=0x4cf588:[0x4cf5a8] (ISA=A64) E iBR A64:ret ) Idx:405; ID:12; [0x95 0xd1 0xdf ]; I_ADDR_S_IS0 : Address, Short, IS0.; Addr=0x00000000004DBF44 ~[0x1BF44] Idx:408; ID:12; [0xe0 ]; I_ATOM_F6 : Atom format 6.; EEEN Idx:408; ID:12; OCSD_GEN_TRC_ELEM_INSTR_RANGE(exec range=0x4dbf44:[0x4dbf6c] (ISA=A64) E BR )
The OCSD_GEN_TRC_ELEM_INSTR_RANGE packets are instruction executed ranges, address inclusive to exclusive. The perf tool uses this decoder packet output to produce disassembly using perf script and passing the range to the gcc objdump utility for disassembly.
If memory images for the addresses are not included in your snapshot then you will see OCSD_GEN_TRC_ELEM_NACC(<address>) indicating that the decoder could not access the address present in the trace data.
Yes, I see OCSD_GEN_TRC_ELEM_NACC(<address>) only, and I noticed the snapshot of TC2 can be decoded out some OCSD_GEN_TRC_ELEM_INSTR_RANGE packets, is it because that includes a memory image called kernel_dump.bin ?
Look at decoder/snapshots/trace_cov_a15 for an example of a snapshot that has multiple memory images for the application executed.
How to dump this kind of memory images? I mean what tools I can use to dump this kind of images, for example kernel image?
What does 'space=S' mean? Why no 'length=..' under [dumpx] in the snapshot of trace_cov_a15, but TC2's has?
Thanks, Chunyan
Hi Chunyan,
On 5 September 2017 at 12:44, Chunyan Zhang zhang.chunyan@linaro.org wrote:
Hi Mike,
On 5 September 2017 at 16:46, Mike Leach mike.leach@linaro.org wrote:
Hi Chunyan,
On Tue, 5 Sep 2017 at 04:19, Chunyan Zhang zhang.chunyan@linaro.org wrote:
Hi Mike,
Thanks for the detailed instructions.
On 4 September 2017 at 23:13, Mike Leach mike.leach@linaro.org wrote:
Hi Chunyan.
There is plenty of documentation for DS-5, but the path from snapshot to trace dump is not obvious so I will give you a few pointers.
- first you need to create a DS-5 configuration that will load your
snapshot.
a) On the menu choose "run->debug configurations" which will open the debug configurations dialog. b) Click the "new configuration button" - leftmost button above the left pane to create a new configuration. c) In the Name: edit box type a new name for this configuration d) on the "connection" tab in the right hand pane navigate to Generic->Snapshot->View Snapshot->ViewSnapshot. e) below this browse for the snapshot.ini file you want to use in the configuration by clicking the File... button and select a file. See attached ds-5-debug-config.png for picture of above dialog.
f) On the "debugger" tab, select the "connect only" radio button in the Run Control area. Hit "Apply" and "close" and you new "Snapshot connection" should be visible in the "debug Control" tab in DS-5. Right click, hit connect and DS-5 should load the snapshot.
We have to ensure the target is connecting with DStream when hit connect on DS-5, right?
No - snapshot support in DS5 is fully offline.
That's great. I will try again.
But you do need to have the memory images of the applications you traced as part of the snapshot to make decode work correctly.
Is there any way for offline decoding snapshot of raw trace [1] further which I mean decoded by 'trc_pkt_lister'. Since the decoded traces [1] are still not easy to be used for understanding what the system was doing.
t rc_pkt_lister is a test tool for the library so does not have advanced disassembly capability.
You can add the -decode or -decode-only option to the command line to get the trace packets decoded into executed instruction ranges and obtain output similar to that below:-
Idx:348; ID:12; [0xdd 0xf9 0xf5 0xdf 0xfc 0xf9 0xdc ]; I_NOT_SYNC : I Stream not synchronised Idx:356; ID:12; [0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x80 ]; I_ASYNC : Alignment Synchronisation. Idx:369; ID:12; [0x01 0x01 0x00 ]; I_TRACE_INFO : Trace Info.; INFO=0x0 Idx:372; ID:12; [0xf7 ]; I_ATOM_F1 : Atom format 1.; E Idx:373; ID:12; [0x85 0x22 0x12 0x4d 0x00 0x00 0x00 0x00 0x00 0x30 ]; I_ADDR_CTXT_L_64IS0 : Address & Context, Long, 64 bit, IS0.; Addr=0x00000000004D2488; Ctxt: AArch64,EL0, NS; Idx:384; ID:12; [0xf7 ]; I_ATOM_F1 : Atom format 1.; E Idx:373; ID:12; OCSD_GEN_TRC_ELEM_PE_CONTEXT((ISA=Unk) EL0N; 64-bit; ) Idx:384; ID:12; OCSD_GEN_TRC_ELEM_INSTR_RANGE(exec range=0x4d2488:[0x4d2494] (ISA=A64) E iBR A64:ret ) Idx:385; ID:12; [0x9d 0x48 0x5f 0x4d 0x00 0x00 0x00 0x00 0x00 ]; I_ADDR_L_64IS0 : Address, Long, 64 bit, IS0.; Addr=0x00000000004DBF20; Idx:394; ID:12; [0xde ]; I_ATOM_F4 : Atom format 4.; NENE Idx:394; ID:12; OCSD_GEN_TRC_ELEM_INSTR_RANGE(exec range=0x4dbf20:[0x4dbf24] (ISA=A64) N BR ) Idx:394; ID:12; OCSD_GEN_TRC_ELEM_INSTR_RANGE(exec range=0x4dbf24:[0x4dbf2c] (ISA=A64) E BR b+link ) Idx:394; ID:12; OCSD_GEN_TRC_ELEM_INSTR_RANGE(exec range=0x4d1d88:[0x4d1db4] (ISA=A64) N BR ) Idx:394; ID:12; OCSD_GEN_TRC_ELEM_INSTR_RANGE(exec range=0x4d1db4:[0x4d1dbc] (ISA=A64) E BR ) Idx:395; ID:12; [0xdb ]; I_ATOM_F2 : Atom format 2.; EE Idx:395; ID:12; OCSD_GEN_TRC_ELEM_INSTR_RANGE(exec range=0x4d1dd8:[0x4d1df0] (ISA=A64) E BR ) Idx:395; ID:12; OCSD_GEN_TRC_ELEM_INSTR_RANGE(exec range=0x4d1dbc:[0x4d1dd8] (ISA=A64) E iBR A64:ret ) Idx:396; ID:12; [0x95 0x4b ]; I_ADDR_S_IS0 : Address, Short, IS0.; Addr=0x00000000004DBF2C ~[0x12C] Idx:398; ID:12; [0xe0 ]; I_ATOM_F6 : Atom format 6.; EEEN Idx:398; ID:12; OCSD_GEN_TRC_ELEM_INSTR_RANGE(exec range=0x4dbf2c:[0x4dbf38] (ISA=A64) E BR ) Idx:398; ID:12; OCSD_GEN_TRC_ELEM_INSTR_RANGE(exec range=0x4dc0cc:[0x4dc0d8] (ISA=A64) E BR ) Idx:398; ID:12; OCSD_GEN_TRC_ELEM_INSTR_RANGE(exec range=0x4dbf38:[0x4dbf44] (ISA=A64) E BR b+link ) Idx:398; ID:12; OCSD_GEN_TRC_ELEM_INSTR_RANGE(exec range=0x4cf4b0:[0x4cf4d0] (ISA=A64) N BR ) Idx:400; ID:12; [0xdb ]; I_ATOM_F2 : Atom format 2.; EE Idx:400; ID:12; OCSD_GEN_TRC_ELEM_INSTR_RANGE(exec range=0x4cf4d0:[0x4cf500] (ISA=A64) E BR ) Idx:400; ID:12; OCSD_GEN_TRC_ELEM_INSTR_RANGE(exec range=0x4cf5a8:[0x4cf5bc] (ISA=A64) E iBR ) Idx:401; ID:12; [0x95 0x88 0x7b ]; I_ADDR_S_IS0 : Address, Short, IS0.; Addr=0x00000000004CF620 ~[0xF620] Idx:404; ID:12; [0xdc ]; I_ATOM_F4 : Atom format 4.; NEEE Idx:404; ID:12; OCSD_GEN_TRC_ELEM_INSTR_RANGE(exec range=0x4cf620:[0x4cf62c] (ISA=A64) N BR ) Idx:404; ID:12; OCSD_GEN_TRC_ELEM_INSTR_RANGE(exec range=0x4cf62c:[0x4cf63c] (ISA=A64) E BR ) Idx:404; ID:12; OCSD_GEN_TRC_ELEM_INSTR_RANGE(exec range=0x4cf7bc:[0x4cf7d8] (ISA=A64) E BR ) Idx:404; ID:12; OCSD_GEN_TRC_ELEM_INSTR_RANGE(exec range=0x4cf588:[0x4cf5a8] (ISA=A64) E iBR A64:ret ) Idx:405; ID:12; [0x95 0xd1 0xdf ]; I_ADDR_S_IS0 : Address, Short, IS0.; Addr=0x00000000004DBF44 ~[0x1BF44] Idx:408; ID:12; [0xe0 ]; I_ATOM_F6 : Atom format 6.; EEEN Idx:408; ID:12; OCSD_GEN_TRC_ELEM_INSTR_RANGE(exec range=0x4dbf44:[0x4dbf6c] (ISA=A64) E BR )
The OCSD_GEN_TRC_ELEM_INSTR_RANGE packets are instruction executed ranges, address inclusive to exclusive. The perf tool uses this decoder packet output to produce disassembly using perf script and passing the range to the gcc objdump utility for disassembly.
If memory images for the addresses are not included in your snapshot then you will see OCSD_GEN_TRC_ELEM_NACC(<address>) indicating that the decoder could not access the address present in the trace data.
Yes, I see OCSD_GEN_TRC_ELEM_NACC(<address>) only, and I noticed the snapshot of TC2 can be decoded out some OCSD_GEN_TRC_ELEM_INSTR_RANGE packets, is it because that includes a memory image called kernel_dump.bin ?
Yes.
Look at decoder/snapshots/trace_cov_a15 for an example of a snapshot that has multiple memory images for the application executed.
How to dump this kind of memory images? I mean what tools I can use to dump this kind of images, for example kernel image?
You can use DS-5 to dump memory from the running target. Alternatively perf uses the application / library binaries themselves - you need to know the offsets into the files that the code sections start but that comes in the .elf information. In this case the dump entry would need an offset and size parameter.
What does 'space=S' mean? Why no 'length=..' under [dumpx] in the snapshot of trace_cov_a15, but TC2's has?
Some parameters are optional - but as mentioned above if you are supplying an .elf format file, the code section that would be loaded into memory will have an offset and a length into the file. The definitions for the snapshot formats are in the OpenCSD library project - look at the .pdf under decoder/docs/specs - section 3.2.3 describes the [dump] sections.
Regards
Mike
Thanks, Chunyan
Hi Mike,
On 5 September 2017 at 20:24, Mike Leach mike.leach@linaro.org wrote:
[snip]
On 4 September 2017 at 23:13, Mike Leach mike.leach@linaro.org wrote:
Hi Chunyan.
There is plenty of documentation for DS-5, but the path from snapshot to trace dump is not obvious so I will give you a few pointers.
- first you need to create a DS-5 configuration that will load your
snapshot.
a) On the menu choose "run->debug configurations" which will open the debug configurations dialog. b) Click the "new configuration button" - leftmost button above the left pane to create a new configuration. c) In the Name: edit box type a new name for this configuration d) on the "connection" tab in the right hand pane navigate to Generic->Snapshot->View Snapshot->ViewSnapshot. e) below this browse for the snapshot.ini file you want to use in the configuration by clicking the File... button and select a file. See attached ds-5-debug-config.png for picture of above dialog.
f) On the "debugger" tab, select the "connect only" radio button in the Run Control area. Hit "Apply" and "close" and you new "Snapshot connection" should be visible in the "debug Control" tab in DS-5. Right click, hit connect and DS-5 should load the snapshot.
We have to ensure the target is connecting with DStream when hit connect on DS-5, right?
No - snapshot support in DS5 is fully offline.
That's great. I will try again.
But you do need to have the memory images of the applications you traced as part of the snapshot to make decode work correctly.
Is there any way for offline decoding snapshot of raw trace [1] further which I mean decoded by 'trc_pkt_lister'. Since the decoded traces [1] are still not easy to be used for understanding what the system was doing.
t rc_pkt_lister is a test tool for the library so does not have advanced disassembly capability.
You can add the -decode or -decode-only option to the command line to get the trace packets decoded into executed instruction ranges and obtain output similar to that below:-
Idx:348; ID:12; [0xdd 0xf9 0xf5 0xdf 0xfc 0xf9 0xdc ]; I_NOT_SYNC : I Stream not synchronised Idx:356; ID:12; [0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x80 ]; I_ASYNC : Alignment Synchronisation. Idx:369; ID:12; [0x01 0x01 0x00 ]; I_TRACE_INFO : Trace Info.; INFO=0x0 Idx:372; ID:12; [0xf7 ]; I_ATOM_F1 : Atom format 1.; E Idx:373; ID:12; [0x85 0x22 0x12 0x4d 0x00 0x00 0x00 0x00 0x00 0x30 ]; I_ADDR_CTXT_L_64IS0 : Address & Context, Long, 64 bit, IS0.; Addr=0x00000000004D2488; Ctxt: AArch64,EL0, NS; Idx:384; ID:12; [0xf7 ]; I_ATOM_F1 : Atom format 1.; E Idx:373; ID:12; OCSD_GEN_TRC_ELEM_PE_CONTEXT((ISA=Unk) EL0N; 64-bit; ) Idx:384; ID:12; OCSD_GEN_TRC_ELEM_INSTR_RANGE(exec range=0x4d2488:[0x4d2494] (ISA=A64) E iBR A64:ret ) Idx:385; ID:12; [0x9d 0x48 0x5f 0x4d 0x00 0x00 0x00 0x00 0x00 ]; I_ADDR_L_64IS0 : Address, Long, 64 bit, IS0.; Addr=0x00000000004DBF20; Idx:394; ID:12; [0xde ]; I_ATOM_F4 : Atom format 4.; NENE Idx:394; ID:12; OCSD_GEN_TRC_ELEM_INSTR_RANGE(exec range=0x4dbf20:[0x4dbf24] (ISA=A64) N BR ) Idx:394; ID:12; OCSD_GEN_TRC_ELEM_INSTR_RANGE(exec range=0x4dbf24:[0x4dbf2c] (ISA=A64) E BR b+link ) Idx:394; ID:12; OCSD_GEN_TRC_ELEM_INSTR_RANGE(exec range=0x4d1d88:[0x4d1db4] (ISA=A64) N BR ) Idx:394; ID:12; OCSD_GEN_TRC_ELEM_INSTR_RANGE(exec range=0x4d1db4:[0x4d1dbc] (ISA=A64) E BR ) Idx:395; ID:12; [0xdb ]; I_ATOM_F2 : Atom format 2.; EE Idx:395; ID:12; OCSD_GEN_TRC_ELEM_INSTR_RANGE(exec range=0x4d1dd8:[0x4d1df0] (ISA=A64) E BR ) Idx:395; ID:12; OCSD_GEN_TRC_ELEM_INSTR_RANGE(exec range=0x4d1dbc:[0x4d1dd8] (ISA=A64) E iBR A64:ret ) Idx:396; ID:12; [0x95 0x4b ]; I_ADDR_S_IS0 : Address, Short, IS0.; Addr=0x00000000004DBF2C ~[0x12C] Idx:398; ID:12; [0xe0 ]; I_ATOM_F6 : Atom format 6.; EEEN Idx:398; ID:12; OCSD_GEN_TRC_ELEM_INSTR_RANGE(exec range=0x4dbf2c:[0x4dbf38] (ISA=A64) E BR ) Idx:398; ID:12; OCSD_GEN_TRC_ELEM_INSTR_RANGE(exec range=0x4dc0cc:[0x4dc0d8] (ISA=A64) E BR ) Idx:398; ID:12; OCSD_GEN_TRC_ELEM_INSTR_RANGE(exec range=0x4dbf38:[0x4dbf44] (ISA=A64) E BR b+link ) Idx:398; ID:12; OCSD_GEN_TRC_ELEM_INSTR_RANGE(exec range=0x4cf4b0:[0x4cf4d0] (ISA=A64) N BR ) Idx:400; ID:12; [0xdb ]; I_ATOM_F2 : Atom format 2.; EE Idx:400; ID:12; OCSD_GEN_TRC_ELEM_INSTR_RANGE(exec range=0x4cf4d0:[0x4cf500] (ISA=A64) E BR ) Idx:400; ID:12; OCSD_GEN_TRC_ELEM_INSTR_RANGE(exec range=0x4cf5a8:[0x4cf5bc] (ISA=A64) E iBR ) Idx:401; ID:12; [0x95 0x88 0x7b ]; I_ADDR_S_IS0 : Address, Short, IS0.; Addr=0x00000000004CF620 ~[0xF620] Idx:404; ID:12; [0xdc ]; I_ATOM_F4 : Atom format 4.; NEEE Idx:404; ID:12; OCSD_GEN_TRC_ELEM_INSTR_RANGE(exec range=0x4cf620:[0x4cf62c] (ISA=A64) N BR ) Idx:404; ID:12; OCSD_GEN_TRC_ELEM_INSTR_RANGE(exec range=0x4cf62c:[0x4cf63c] (ISA=A64) E BR ) Idx:404; ID:12; OCSD_GEN_TRC_ELEM_INSTR_RANGE(exec range=0x4cf7bc:[0x4cf7d8] (ISA=A64) E BR ) Idx:404; ID:12; OCSD_GEN_TRC_ELEM_INSTR_RANGE(exec range=0x4cf588:[0x4cf5a8] (ISA=A64) E iBR A64:ret ) Idx:405; ID:12; [0x95 0xd1 0xdf ]; I_ADDR_S_IS0 : Address, Short, IS0.; Addr=0x00000000004DBF44 ~[0x1BF44] Idx:408; ID:12; [0xe0 ]; I_ATOM_F6 : Atom format 6.; EEEN Idx:408; ID:12; OCSD_GEN_TRC_ELEM_INSTR_RANGE(exec range=0x4dbf44:[0x4dbf6c] (ISA=A64) E BR )
The OCSD_GEN_TRC_ELEM_INSTR_RANGE packets are instruction executed ranges, address inclusive to exclusive. The perf tool uses this decoder packet output to produce disassembly using perf script and passing the range to the gcc objdump utility for disassembly.
If memory images for the addresses are not included in your snapshot then you will see OCSD_GEN_TRC_ELEM_NACC(<address>) indicating that the decoder could not access the address present in the trace data.
Yes, I see OCSD_GEN_TRC_ELEM_NACC(<address>) only, and I noticed the snapshot of TC2 can be decoded out some OCSD_GEN_TRC_ELEM_INSTR_RANGE packets, is it because that includes a memory image called kernel_dump.bin ?
Yes.
Look at decoder/snapshots/trace_cov_a15 for an example of a snapshot that has multiple memory images for the application executed.
How to dump this kind of memory images? I mean what tools I can use to dump this kind of images, for example kernel image?
You can use DS-5 to dump memory from the running target. Alternatively perf uses the application / library binaries themselves
- you need to know the offsets into the files that the code sections
start but that comes in the .elf information. In this case the dump entry would need an offset and size parameter.
I will try.
What does 'space=S' mean? Why no 'length=..' under [dumpx] in the snapshot of trace_cov_a15, but TC2's has?
Some parameters are optional - but as mentioned above if you are supplying an .elf format file, the code section that would be loaded into memory will have an offset and a length into the file. The definitions for the snapshot formats are in the OpenCSD library project - look at the .pdf under decoder/docs/specs - section 3.2.3 describes the [dump] sections.
Didn't notice this file before, it is really helpful for me.
Thanks for your answers :)
Chunyan
Regards
Mike
Thanks, Chunyan
-- Mike Leach Principal Engineer, ARM Ltd. Blackburn Design Centre. UK
-
Chunyan Zhang -
Mike Leach