Hi,
Following my previous email (which you might not have received yet, because the attached snapshot was slightly over the size limit), I have written a small patch to address the issue I found with ETMv4 decoding.
For clarity, the issue I encountered was that in EtmV4ITrcPkt::updateShortAddress, when the v_addr field is computed, it uses the old value (which is supposed to be the last broadcast address, according to the documentation). However, when an Exact Match packet is output, the specification says that the matched address is pushed at the front of the address queue. The v_addr field looks to me like it is the top of the address queue, so should be updated in EtmV4ITrcPacket::setAddressExactMatch, which is currently not done.
The patch I wrote replicates the address queue in the EtmV4ITrcPacket class, to update the last broadcast address accordingly when reading an exact match. There is a bit of redundancy, because it is also done in the TrcPktDecodeEtmV4I class, but it seems to fix the problem.
You will find the patch attached to this email.
Below is the output for the section that showed an incorrect output. Idx:4248; ID:12; I_ADDR_S_IS0 : Address, Short, IS0.; Addr=0x004DC2DC ~[0xDC] Idx:4250; ID:12; I_ATOM_F3 : Atom format 3.; EEN Idx:4251; ID:12; I_ATOM_F2 : Atom format 2.; EE Idx:4252; ID:12; I_ADDR_S_IS0 : Address, Short, IS0.; Addr=0x004D004C ~[0x1004C] Idx:4256; ID:12; I_ATOM_F1 : Atom format 1.; E Idx:4257; ID:12; I_ADDR_S_IS0 : Address, Short, IS0.; Addr=0x004DCC6C ~[0x1CC6C] Idx:4260; ID:12; I_ATOM_F3 : Atom format 3.; EEN Idx:4261; ID:12; I_ATOM_F3 : Atom format 3.; NNE Idx:4262; ID:12; I_ATOM_F3 : Atom format 3.; EEN Idx:4263; ID:12; I_ATOM_F2 : Atom format 2.; EE Idx:4264; ID:12; I_ADDR_MATCH : Exact Address Match., [1] Idx:4265; ID:12; I_ATOM_F1 : Atom format 1.; E Idx:4266; ID:12; I_ADDR_S_IS0 : Address, Short, IS0.; Addr=0x004D00F4 ~[0xF4]
The last address is constructed from 0x004D004C, which is at the top of the address queue after the Exact Match. Before the patch, it was constructed from 0x004DCC6C, which was at the top of the address queue *before* the Exact Match, and at index 1 after.
I hope you can add this patch to the library at some point, or a modified version of it.
Best regards,
Thierry Laviron 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.
On Tue, 22 Aug 2017 14:49:47 +0000 Thierry Laviron Thierry.Laviron@arm.com wrote:
Hi,
Following my previous email (which you might not have received yet, because the attached snapshot was slightly over the size limit), I have written a small patch to address the issue I found with ETMv4 decoding.
Without delving into the subject matter, I tried running an OpenCSD-built 'perf report -D' on the same perf.data file, and found some decoder data goes missing with this patch, like the Es and Ns for example:
--- dump 2017-08-22 15:54:05.207041851 -0500 +++ dump-WITHthierry 2017-08-22 15:43:31.884817645 -0500 @@ -235,3496 +235,3496 @@ 128: id[16] I_NOT_SYNC : I Stream not synchronised 4638: id[16] I_ASYNC : Alignment Synchronisation. 4651: id[16] I_TRACE_INFO : Trace Info.; INFO=0x0 - 4654: id[16] I_ADDR_CTXT_L_64IS0 : Address & Context, Long, 64 bit, IS0.; Addr=0xFFFF0000081D3BC8; Ctxt: AArch64,EL1, NS; - 4665: id[16] I_ATOM_F3 : Atom format 3.; NEE + 4654: id[16] I_ADDR_CTXT_L_64IS0 : Address & Context, Long, 64 bit, IS0.; Addr=0xFFFF0000081D3BC8; + 4665: id[16] I_ATOM_F3 : Atom format 3.; 4666: id[16] I_ADDR_L_64IS0 : Address, Long, 64 bit, IS0.; Addr=0xFFFF0000081D6EC0; - 4676: id[16] I_ATOM_F2 : Atom format 2.; NE + 4676: id[16] I_ATOM_F2 : Atom format 2.; 4677: id[16] I_ADDR_S_IS0 : Address, Short, IS0.; Addr=0xFFFF0000081D7160 ~[0x17160] - 4680: id[16] I_ATOM_F3 : Atom format 3.; ENE - 4681: id[16] I_ATOM_F3 : Atom format 3.; EEN - 4682: id[16] I_ATOM_F1 : Atom format 1.; E + 4680: id[16] I_ATOM_F3 : Atom format 3.; + 4681: id[16] I_ATOM_F3 : Atom format 3.; + 4682: id[16] I_ATOM_F1 : Atom format 1.; 4683: id[16] I_ADDR_S_IS0 : Address, Short, IS0.; Addr=0xFFFF0000081D6FD0 ~[0x16FD0] - 4686: id[16] I_ATOM_F1 : Atom format 1.; E + 4686: id[16] I_ATOM_F1 : Atom format 1.; 4688: id[16] I_ADDR_S_IS0 : Address, Short, IS0.; Addr=0xFFFF0000081DD870 ~[0x1D870] - 4691: id[16] I_ATOM_F3 : Atom format 3.; ENN - 4692: id[16] I_ATOM_F3 : Atom format 3.; EEN - 4693: id[16] I_ATOM_F4 : Atom format 4.; NNNN - 4694: id[16] I_ATOM_F3 : Atom format 3.; ENE + 4691: id[16] I_ATOM_F3 : Atom format 3.; + 4692: id[16] I_ATOM_F3 : Atom format 3.; + 4693: id[16] I_ATOM_F4 : Atom format 4.; + 4694: id[16] I_ATOM_F3 : Atom format 3.; <snip>
Thanks,
Kim
Hi Kim,
I tried reproducing your bug, without success. I tried applying my patch on top of the OpenCSD master branch, using both debug and release configurations for OpenCSD. I also updated the version of perf from the latest perf-opencsd-master branch, built against the most recent library version with my patch added.
Using either 'trc_pkt_lister' or 'perf report -D', I did not find any Atom packets missing the Atom information in the log.
Since I don't think my patch should affect printing of Atom data, or context data in address & context packets, I have a few questions to ask you.
Is it only a specific portion of the trace report where Atoms are printed out without their values, or does it happen across the whole report? Is it specific to a particular perf.data report, or does it happen consistently across varying perf.data reports?
I may have a guess as to why this might happen: Because I have changed the size of the ocsd_etmv4_i_pkt structure, offsets for several fields will have changed. Maybe the file containing the structure has been recompiled, but not other files that use it (mostly the EtmV4ITrcPacket class in decoder/source/etmv4/trc_pkt_elem_etmv4i.cpp), and this class would be using the old offsets, which would then read the wrong data.
Perhaps a complete rebuild of the library might solve your issue, please let me know if this works
-----Original Message----- From: Kim Phillips [mailto:kim.phillips@arm.com] Sent: 22 August 2017 22:05 To: Thierry Laviron Thierry.Laviron@arm.com Cc: coresight@lists.linaro.org; Daniel Blackwell Daniel.Blackwell@arm.com Subject: Re: OpenCSD ETMv4 decode patch
On Tue, 22 Aug 2017 14:49:47 +0000 Thierry Laviron Thierry.Laviron@arm.com wrote:
Hi,
Following my previous email (which you might not have received yet, because the attached snapshot was slightly over the size limit), I have written a small patch to address the issue I found with ETMv4 decoding.
Without delving into the subject matter, I tried running an OpenCSD-built 'perf report -D' on the same perf.data file, and found some decoder data goes missing with this patch, like the Es and Ns for example:
--- dump 2017-08-22 15:54:05.207041851 -0500 +++ dump-WITHthierry 2017-08-22 15:43:31.884817645 -0500 @@ -235,3496 +235,3496 @@ 128: id[16] I_NOT_SYNC : I Stream not synchronised 4638: id[16] I_ASYNC : Alignment Synchronisation. 4651: id[16] I_TRACE_INFO : Trace Info.; INFO=0x0 - 4654: id[16] I_ADDR_CTXT_L_64IS0 : Address & Context, Long, 64 bit, IS0.; Addr=0xFFFF0000081D3BC8; Ctxt: AArch64,EL1, NS; - 4665: id[16] I_ATOM_F3 : Atom format 3.; NEE + 4654: id[16] I_ADDR_CTXT_L_64IS0 : Address & Context, Long, 64 bit, + IS0.; Addr=0xFFFF0000081D3BC8; + 4665: id[16] I_ATOM_F3 : Atom format 3.; 4666: id[16] I_ADDR_L_64IS0 : Address, Long, 64 bit, IS0.; Addr=0xFFFF0000081D6EC0; - 4676: id[16] I_ATOM_F2 : Atom format 2.; NE + 4676: id[16] I_ATOM_F2 : Atom format 2.; 4677: id[16] I_ADDR_S_IS0 : Address, Short, IS0.; Addr=0xFFFF0000081D7160 ~[0x17160] - 4680: id[16] I_ATOM_F3 : Atom format 3.; ENE - 4681: id[16] I_ATOM_F3 : Atom format 3.; EEN - 4682: id[16] I_ATOM_F1 : Atom format 1.; E + 4680: id[16] I_ATOM_F3 : Atom format 3.; + 4681: id[16] I_ATOM_F3 : Atom format 3.; + 4682: id[16] I_ATOM_F1 : Atom format 1.; 4683: id[16] I_ADDR_S_IS0 : Address, Short, IS0.; Addr=0xFFFF0000081D6FD0 ~[0x16FD0] - 4686: id[16] I_ATOM_F1 : Atom format 1.; E + 4686: id[16] I_ATOM_F1 : Atom format 1.; 4688: id[16] I_ADDR_S_IS0 : Address, Short, IS0.; Addr=0xFFFF0000081DD870 ~[0x1D870] - 4691: id[16] I_ATOM_F3 : Atom format 3.; ENN - 4692: id[16] I_ATOM_F3 : Atom format 3.; EEN - 4693: id[16] I_ATOM_F4 : Atom format 4.; NNNN - 4694: id[16] I_ATOM_F3 : Atom format 3.; ENE + 4691: id[16] I_ATOM_F3 : Atom format 3.; + 4692: id[16] I_ATOM_F3 : Atom format 3.; + 4693: id[16] I_ATOM_F4 : Atom format 4.; + 4694: id[16] I_ATOM_F3 : Atom format 3.; <snip>
Thanks,
Kim 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.
Hi,
Attached is a patch to fix up the issue raised by Thierry. Slightly more extensive than the one created by Thierry as removes redundant address stack on the packet decoder side, moving everything into the packet processor - which fixes the incorrect address issues Thierry found.
Regards
Mike
On 23 August 2017 at 11:20, Thierry Laviron Thierry.Laviron@arm.com wrote:
Hi Kim,
I tried reproducing your bug, without success. I tried applying my patch on top of the OpenCSD master branch, using both debug and release configurations for OpenCSD. I also updated the version of perf from the latest perf-opencsd-master branch, built against the most recent library version with my patch added.
Using either 'trc_pkt_lister' or 'perf report -D', I did not find any Atom packets missing the Atom information in the log.
Since I don't think my patch should affect printing of Atom data, or context data in address & context packets, I have a few questions to ask you.
Is it only a specific portion of the trace report where Atoms are printed out without their values, or does it happen across the whole report? Is it specific to a particular perf.data report, or does it happen consistently across varying perf.data reports?
I may have a guess as to why this might happen: Because I have changed the size of the ocsd_etmv4_i_pkt structure, offsets for several fields will have changed. Maybe the file containing the structure has been recompiled, but not other files that use it (mostly the EtmV4ITrcPacket class in decoder/source/etmv4/trc_pkt_elem_etmv4i.cpp), and this class would be using the old offsets, which would then read the wrong data.
Perhaps a complete rebuild of the library might solve your issue, please let me know if this works
-----Original Message----- From: Kim Phillips [mailto:kim.phillips@arm.com] Sent: 22 August 2017 22:05 To: Thierry Laviron Thierry.Laviron@arm.com Cc: coresight@lists.linaro.org; Daniel Blackwell Daniel.Blackwell@arm.com Subject: Re: OpenCSD ETMv4 decode patch
On Tue, 22 Aug 2017 14:49:47 +0000 Thierry Laviron Thierry.Laviron@arm.com wrote:
Hi,
Following my previous email (which you might not have received yet, because the attached snapshot was slightly over the size limit), I have written a small patch to address the issue I found with ETMv4 decoding.
Without delving into the subject matter, I tried running an OpenCSD-built 'perf report -D' on the same perf.data file, and found some decoder data goes missing with this patch, like the Es and Ns for example:
--- dump 2017-08-22 15:54:05.207041851 -0500 +++ dump-WITHthierry 2017-08-22 15:43:31.884817645 -0500 @@ -235,3496 +235,3496 @@ 128: id[16] I_NOT_SYNC : I Stream not synchronised 4638: id[16] I_ASYNC : Alignment Synchronisation. 4651: id[16] I_TRACE_INFO : Trace Info.; INFO=0x0
- 4654: id[16] I_ADDR_CTXT_L_64IS0 : Address & Context, Long, 64 bit, IS0.; Addr=0xFFFF0000081D3BC8; Ctxt: AArch64,EL1, NS;
- 4665: id[16] I_ATOM_F3 : Atom format 3.; NEE
- 4654: id[16] I_ADDR_CTXT_L_64IS0 : Address & Context, Long, 64 bit,
- IS0.; Addr=0xFFFF0000081D3BC8;
- 4665: id[16] I_ATOM_F3 : Atom format 3.; 4666: id[16] I_ADDR_L_64IS0 : Address, Long, 64 bit, IS0.; Addr=0xFFFF0000081D6EC0;
- 4676: id[16] I_ATOM_F2 : Atom format 2.; NE
- 4676: id[16] I_ATOM_F2 : Atom format 2.; 4677: id[16] I_ADDR_S_IS0 : Address, Short, IS0.; Addr=0xFFFF0000081D7160 ~[0x17160]
- 4680: id[16] I_ATOM_F3 : Atom format 3.; ENE
- 4681: id[16] I_ATOM_F3 : Atom format 3.; EEN
- 4682: id[16] I_ATOM_F1 : Atom format 1.; E
- 4680: id[16] I_ATOM_F3 : Atom format 3.;
- 4681: id[16] I_ATOM_F3 : Atom format 3.;
- 4682: id[16] I_ATOM_F1 : Atom format 1.; 4683: id[16] I_ADDR_S_IS0 : Address, Short, IS0.; Addr=0xFFFF0000081D6FD0 ~[0x16FD0]
- 4686: id[16] I_ATOM_F1 : Atom format 1.; E
- 4686: id[16] I_ATOM_F1 : Atom format 1.; 4688: id[16] I_ADDR_S_IS0 : Address, Short, IS0.; Addr=0xFFFF0000081DD870 ~[0x1D870]
- 4691: id[16] I_ATOM_F3 : Atom format 3.; ENN
- 4692: id[16] I_ATOM_F3 : Atom format 3.; EEN
- 4693: id[16] I_ATOM_F4 : Atom format 4.; NNNN
- 4694: id[16] I_ATOM_F3 : Atom format 3.; ENE
- 4691: id[16] I_ATOM_F3 : Atom format 3.;
- 4692: id[16] I_ATOM_F3 : Atom format 3.;
- 4693: id[16] I_ATOM_F4 : Atom format 4.;
- 4694: id[16] I_ATOM_F3 : Atom format 3.;
<snip>
Thanks,
Kim 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
On Wed, 23 Aug 2017 05:20:37 -0500 Thierry Laviron Thierry.Laviron@arm.com wrote:
Hi Kim,
I tried reproducing your bug, without success. Perhaps a complete rebuild of the library might solve your issue, please let me know if this works
sigh, that appears to be it: fetching, resetting to current tops-of-branches, doing a 'git ls-files -o | xargs rm' before rebuilding using dbg throughout fixes the issue, at least with Mike Leach's later version of the patch.
Sadly - and by no means am I a make expert - I don't see a quick and dirty way to fix the OpenCSD build makefiles to begin to fathom to depend on header files without explicitly listing them as dependencies for each of the objects...
Anyway, thanks,
Kim
-
Kim Phillips -
Mike Leach -
Thierry Laviron