OCSD_ERR_RET_STACK_OVERFLOW with back-to-back exceptions in ETMv4 trace.

[leomao]

Library version: v1.8.1

I am encountering an OCSD_ERR_RET_STACK_OVERFLOW error when decoding a specific ETMv4 trace sequence involving back-to-back exceptions. The packet sequence looks similar to the following:

EXCEPTION
ADDR
...
ATOM_E
EXCEPTION_RETURN
TIMESTAMP
EXCEPTION
ADDR
...

I tried to debug the execution and found:

1. After committing ATOM_E (indicating the exception return), m_return_stack.pop_pending() becomes true.
2. When the library attempts to commit the subsequent EXCEPTION packet, it tries to pop the stack because pop_pending() is true.
3. Since the stack is empty at this point, the library triggers OCSD_ERR_RET_STACK_OVERFLOW.

Based on sections 5.2.8 and 5.3.1 of the ETMv4 specification, it appears the library should not attempt to pop the stack if the preceding ATOM_E indicates an exception return.

I tested adding m_return_stack.clear_pop_pending() within case P0_EXCEP_RET: of TrcPktDecodeEtmV4I::commitElements. The decoding result looks correct for this specific trace. However, I am not sure if this is the correct way to fix this issue.

[mikel-armbb]

The spec says 5.2.7:

"If an exception is taken under certain conditions, then the trace unit must generate an Address element before the
Exception element, unless the Address element would be removed due to a return stack match. The conditions under
which this scenario might be necessary are:
• The exception is taken at the target of a taken indirect branch."

Now, as far as I can tell, the ATOM_E + Exception return occurred as a result of a taken indirect branch. Thus an address element must occur before the exception element - unless as the address could be removed as part of the return stack.
So if the return stack is active - and I presume it is, then the only reason there is not an ADDR packet before the second EXCEPTION is that is was removed by a return stack match.

Can you provide more information on the sequence - the real data in form of a snapshot as shown in the OpenCSD tests would be ideal. Alternately the trace data for the short sequence described along with the code executed.

What is the core and the version of ETM 4 in use?

At this point the sequence you are quoting does not look valid trace.

[leomao]

Thanks for pointing out section 5.2.7. The core is Cortex-R52.
I used trc_pkt_lister to extract the sequence (redacted for brevity):

Idx:713; ID:42; I_ATOM_F1 : Atom format 1.; E
Idx:714; ID:42; I_EXCEPT_RTN : Exception Return.
Idx:715; ID:42; I_TIMESTAMP : Timestamp.; Updated val = <REDACTED>
Idx:717; ID:42; I_EXCEPT : Exception.;  IRQ; Ret Addr Follows, Match Prev;
Frame Data; Index    720;   ID_DATA[0x42]; <REDACTED> 
Idx:720; ID:42; I_ADDR_MATCH : Exact Address Match., [2]; Addr=<REDACTED>;

According to section 6.4.5, I believe the required address element is packed within the exception packet itself, as indicated by [E1:E0] = 0b10.