After mret/sret retires, the privilege mode is switched at the same time, but pc missing situation occurs in a scene (details are described below).

[ZeyueShen]

figure 1

figure 2
The pc flow shown in the figure 1, according to E-Trace Spec, address 8000101c will generate formart1\2 pkt. When mret is executed and the privilege mode changes, the priority of the algorithm will generate formart3 sub0 pkt（shown in figure 2), But the packet address is 80001020. The same address also exists in the pc flow before mret, which will cause the pc to be lost when decoder decoding(shown in figure 3)

figure 3

[IainCRobertson]

If you follow the refence decoder algorithm in Chapter 11 of the E-Trace spec, there will be nothing lost. Upon receipt of the format 3 subformat 0 packet produced by the MRET, the decoder will follow the execution path from 8000101c until it encounters address 80001020 at the target of an uninferable discontinuity. The next_pc function will not set ‘stop_here’ to TRUE until this piece of code: else if (is_uninferable_discon(instr)) if (stop_at_last_branch) ERROR: unexpected uninferable discontinuity else pc = address stop_here = TRUE As is_uninferable_discon() will not be true until the instruction following the mret Iain From: ZeyueShen ***@***.***> Sent: Tuesday, January 2, 2024 2:45 AM To: riscv-non-isa/riscv-trace-spec ***@***.***> Cc: Subscribed ***@***.***> Subject: [riscv-non-isa/riscv-trace-spec] After mret/sret retires, the privilege mode is switched at the same time, but pc missing situation occurs in a scene (details are described below). (Issue #89) clipbord_1704162679288.png (view on web)<https://github.com/riscv-non-isa/riscv-trace-spec/assets/99624852/3120683b-c068-4ab9-92f4-d5afa8a318d4> figure 1 clipbord_1704163006373.png (view on web)<https://github.com/riscv-non-isa/riscv-trace-spec/assets/99624852/df59ebfc-e436-4410-93a0-16487fbdea52> figure 2 The pc flow shown in the figure 1, according to E-Trace Spec, address 8000101c will generate formart1\2 pkt. When mret is executed and the privilege mode changes, the priority of the algorithm will generate formart3 sub0 pkt（shown in figure 2), But the packet address is 80001020. The same address also exists in the pc flow before mret, which will cause the pc to be lost when decoder decoding(shown in figure 3) clipbord_1704163452822.png (view on web)<https://github.com/riscv-non-isa/riscv-trace-spec/assets/99624852/96e0346a-3222-497f-8978-c06bc0e17f17> figure 3 - Reply to this email directly, view it on GitHub<#89>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/ALQOPSXKR72LXQILPHTYSODYMNYETAVCNFSM6AAAAABBJPTXXOVHI2DSMVQWIX3LMV43ASLTON2WKOZSGA3DCOBYHA4DCOA>. You are receiving this because you are subscribed to this thread.Message ID: ***@***.******@***.***>>

[ZeyueShen]

Thanks for your answer, I understand what you mean, but in this scenario, address 80001020 appears before mret, and there are no other branches in between, so according to the code in Chapter 11 (as shown in Figure 1), it will end at 80001020 before mret.

Figure 1

[IainCRobertson]

Thanks, I'm with you now. There is an omission in the decoder pseudo-code in the spec. In fact, we have encountered this before and the decoder that we use includes a fix for this (detailed below). I will create a Pull Request to get this fixed in the spec. The changes required are as follows (new or changed lines highlighted): Include an additional global variable: global privilege # Privilege from te_inst messages Assign it in process_te_inst: if (te_inst.format == 3) ... ... privilege = te_inst.privilege start_of_trace = FALSE else # Not format 3 To keep the code tidy, add a new function is_return_from_trap: # Determine if instruction is a return from trap ########################################################## function is_return_from_trap (instr) if ((instr.opcode == URET) or (instr.opcode == SRET) or (instr.opcode == MRET) or (instr.opcode == DRET)) return TRUE return FALSE And refactor is_inferrable_discon to use this (no functional change here): # Determine if instruction is an uninferrable discontinuity ############################################### function is_uninferrable_discon (instr) if (is_uninferrable_jump(instr) or is_return_from_trap (instr) or (instr.opcode == ECALL) or (instr.opcode == EBREAK) or (instr.opcode == C.EBREAK)) return TRUE return FALSE Then modify the final clause in follow_execution_path: if (te_inst.format == 3 and pc == address and (branches != (is_branch(get_instr(pc)) ? 1 : 0)) and (te_inst.privilege == privilege or is_return_from_trap(get_instr(last_pc)))) # All branches processed, and reached reported address return Iain From: ZeyueShen ***@***.***> Sent: Wednesday, January 3, 2024 1:33 AM To: riscv-non-isa/riscv-trace-spec ***@***.***> Cc: Robertson, Iain (DI SW ICS TST RD EAH) ***@***.***>; Comment ***@***.***> Subject: Re: [riscv-non-isa/riscv-trace-spec] After mret/sret retires, the privilege mode is switched at the same time, but pc missing situation occurs in a scene (details are described below). (Issue #89) Thanks for your answer, I understand what you mean, but in this scenario, address 80001020 appears before mret, and there are no other branches in between, so according to the code in Chapter 11 (as shown in Figure 1), it will end at 80001020 before mret. clipbord_1704245174829.png (view on web)<https://github.com/riscv-non-isa/riscv-trace-spec/assets/99624852/5051e7c3-7db3-4d3d-9d03-25e89d427b3a> Figure 1 - Reply to this email directly, view it on GitHub<#89 (comment)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/ALQOPSXHPGMTJIGE72XGYJ3YMSYL7AVCNFSM6AAAAABBJPTXXOVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTQNZUG42TEMRUGQ>. You are receiving this because you commented.Message ID: ***@***.******@***.***>>

[ZeyueShen]

Well, thank you very much for your answer

Zeyue Shen