Incorrect Implicit Return Information in Trace Packets

[IainCRobertson]

The implicit_return mode information included in format 0/1/2 packets (specifically, the irdepth field) does not produce correct trace decoding in many cases.

Reporting the current stack depth is helpful for decoding recursive functions, but provides no information about the number of functions successfully executed previously. The decoder does not need to know the current stack depth - it needs to know the total number of function returns that were not explicitly reported.

This is a longstanding bug in the E-trace 2.0 spec. Regrettably, implicit return was not validated end to end (encode and decode) before ratification.

Spec update, including revised decoder pseudo-code that includes implicit return as well as branch predictor and jump target cache support for the 1st time here: #253

[IainCRobertson]

A little more detail on how and when the current approach fails. Most of the time it works fine. The one case where it does not if where there are functions containing no branches or uninferrable calls/jumps. Consider the following example:

A function is executed, and returns normally to the predicted target, so nothing is reported.
Execution continues without any branches or uninferrable calls/jumps to a second function which also contains no branches or uninferrable calls/jumps. The return address of this 2nd function is reported for some reason. Doesn't matter why, but the full list of reasons is:

• It was mispredicted, or
• It was followed by an interrupt or exception, or
• It was the final traced instruction

Note that the stack depth is the same after the 1st function returns and after the 2nd function returns. When the decoder reconstructs the execution path, it encounters the 1st return and because the stack depth in the te_inst packet matches the current stack depth it stops decoding at this point, rather than carrying on to the second return.

Had there been any branches between the two functions or inside the 2nd function, decoding would have continued until all branches were processed (the 1st return would have been correctly treated as inferred), and decoding would have stopped at the right place: the return target of the 2nd function. Similarly if there were uninferrable calls/jumps.

So to summarise, the issue arises only when you have one or more functions without any branches or uninferrable calls/jumps between or inside them, where the return from one of these is either mispredicted or immediately followed by a trap or end of trace.