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.