Hi,
I think we have discovered a bug in the ETMv4 decoder, when there is an 'exact match' packet followed by an address packet that is not 64 bit long.
Here is a faulty sample:
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=0x004DCCF4 ~[0xF4]
We have 3 addresses output before the exact match; at that point the state of the address queue is 0: 0x004DCC6C 1: 0x004D004C 2: 0x004DC2DC
After the exact match packet, it should be 0: 0x004D004C 1: 0x004DCC6C 2: 0x004D004C
This means that the next address value should be compared to 0x004D004C The next address packet is a short address, with one byte of data. It tells us bits[8:0] of the next address are 0x0F4 This means the next executed address is 0x004D00F4. However the decoder is interpreting it as 0x004DCCF4, as if it did not update the queue.
Looking at the code, it appears the address queue does get properly updated on an exact match packet, however when reconstructing addresses, it uses an ocsd_etmv4_i_pkt::v_addr field; documentation says this is the "most recently broadcast address packet". This v_addr field does not get updated on an exact match packet, but if I am reading the specifications right it should.
Am I right in assuming this is a bug?
I have attached the snapshot that produces the bug, and the executable that produced the trace so you can check the assembly code.
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.
Hi Thierry,
You are quite right - the output string print output of the packet processor is showing up an incorrect address in the example you provide.
The decode is a two stage process, 1) packet processor - split the incoming byte stream into meaningful packets. 2) packet decode - process the packet stream combinations into ranges of traced instructions.
We do not track the address stack in the packet processor - that is done when actually decoding the packet stream in the next part of the process. The reason for this is that for speculative trace, we might actually throw away some of the address packets - and speculation is only resolved in the decode section. A quick inspection of the code here would indicate that we are correctly pushing the address stack for matches and none matches - but I need to test this further to make sure.
Now to fix the printed output of the packet processor we have two choices: a) On exact match, clear the valid bits in ocsd_etmv4_i_pkt::v_addr - as we no longer know what is going on - this would result in the following addresses _only_ showing the bits that are currently valid - removing the misleading data. b) Track the address stack in the packet processor as well - though this route means the data will become inaccurate again once speculative trace is used.
Currently I am inclined to go with option a) - the packet dump is intended as an indicator of the individual packets, not the combination of multiple packets - the intra packet address tracking was always a convenience, not a key part of the decoder.
Regards
Mike
On 22 August 2017 at 12:11, Thierry Laviron Thierry.Laviron@arm.com wrote:
Hi,
I think we have discovered a bug in the ETMv4 decoder, when there is an ‘exact match’ packet followed by an address packet that is not 64 bit long.
Here is a faulty sample:
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=0x004DCCF4 ~[0xF4]
We have 3 addresses output before the exact match; at that point the state of the address queue is
0: 0x004DCC6C
1: 0x004D004C
2: 0x004DC2DC
After the exact match packet, it should be
0: 0x004D004C
1: 0x004DCC6C
2: 0x004D004C
This means that the next address value should be compared to 0x004D004C
The next address packet is a short address, with one byte of data. It tells us bits[8:0] of the next address are 0x0F4
This means the next executed address is 0x004D00F4.
However the decoder is interpreting it as 0x004DCCF4, as if it did not update the queue.
Looking at the code, it appears the address queue does get properly updated on an exact match packet, however when reconstructing addresses, it uses an ocsd_etmv4_i_pkt::v_addr field; documentation says this is the “most recently broadcast address packet”.
This v_addr field does not get updated on an exact match packet, but if I am reading the specifications right it should.
Am I right in assuming this is a bug?
I have attached the snapshot that produces the bug, and the executable that produced the trace so you can check the assembly code.
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
Hi Thierry,
Having looked at this in more detail, the issue is propogating through to the decode side - so after chatting with JohnH who pointed out that the address stack was used fro creation of address values which may later processed in speculative trace, I have moved the entire address stack tracking code from the decode side to the packet processing side. This should have the desired effect and correct the issues you where seeing.
I've not used your patch directly as there where additional issues that needed updating but I appreciate the effort.
I will release a patch for you an others to look at before end of the day
Thanks and Regards
Mike
On 23 August 2017 at 11:13, Mike Leach mike.leach@linaro.org wrote:
Hi Thierry,
You are quite right - the output string print output of the packet processor is showing up an incorrect address in the example you provide.
The decode is a two stage process,
- packet processor - split the incoming byte stream into meaningful packets.
- packet decode - process the packet stream combinations into ranges
of traced instructions.
We do not track the address stack in the packet processor - that is done when actually decoding the packet stream in the next part of the process. The reason for this is that for speculative trace, we might actually throw away some of the address packets - and speculation is only resolved in the decode section. A quick inspection of the code here would indicate that we are correctly pushing the address stack for matches and none matches - but I need to test this further to make sure.
Now to fix the printed output of the packet processor we have two choices: a) On exact match, clear the valid bits in ocsd_etmv4_i_pkt::v_addr - as we no longer know what is going on - this would result in the following addresses _only_ showing the bits that are currently valid - removing the misleading data. b) Track the address stack in the packet processor as well - though this route means the data will become inaccurate again once speculative trace is used.
Currently I am inclined to go with option a) - the packet dump is intended as an indicator of the individual packets, not the combination of multiple packets - the intra packet address tracking was always a convenience, not a key part of the decoder.
Regards
Mike
On 22 August 2017 at 12:11, Thierry Laviron Thierry.Laviron@arm.com wrote:
Hi,
I think we have discovered a bug in the ETMv4 decoder, when there is an ‘exact match’ packet followed by an address packet that is not 64 bit long.
Here is a faulty sample:
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=0x004DCCF4 ~[0xF4]
We have 3 addresses output before the exact match; at that point the state of the address queue is
0: 0x004DCC6C
1: 0x004D004C
2: 0x004DC2DC
After the exact match packet, it should be
0: 0x004D004C
1: 0x004DCC6C
2: 0x004D004C
This means that the next address value should be compared to 0x004D004C
The next address packet is a short address, with one byte of data. It tells us bits[8:0] of the next address are 0x0F4
This means the next executed address is 0x004D00F4.
However the decoder is interpreting it as 0x004DCCF4, as if it did not update the queue.
Looking at the code, it appears the address queue does get properly updated on an exact match packet, however when reconstructing addresses, it uses an ocsd_etmv4_i_pkt::v_addr field; documentation says this is the “most recently broadcast address packet”.
This v_addr field does not get updated on an exact match packet, but if I am reading the specifications right it should.
Am I right in assuming this is a bug?
I have attached the snapshot that produces the bug, and the executable that produced the trace so you can check the assembly code.
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
-- Mike Leach Principal Engineer, ARM Ltd. Blackburn Design Centre. UK
-
Mike Leach -
Thierry Laviron