Closed ZeyueShen closed 8 months ago
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 GitHubhttps://github.com/riscv-non-isa/riscv-trace-spec/issues/89, or unsubscribehttps://github.com/notifications/unsubscribe-auth/ALQOPSXKR72LXQILPHTYSODYMNYETAVCNFSM6AAAAABBJPTXXOVHI2DSMVQWIX3LMV43ASLTON2WKOZSGA3DCOBYHA4DCOA. You are receiving this because you are subscribed to this thread.Message ID: @.**@.>>
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
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:
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):
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 GitHubhttps://github.com/riscv-non-isa/riscv-trace-spec/issues/89#issuecomment-1874752244, or unsubscribehttps://github.com/notifications/unsubscribe-auth/ALQOPSXHPGMTJIGE72XGYJ3YMSYL7AVCNFSM6AAAAABBJPTXXOVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTQNZUG42TEMRUGQ. You are receiving this because you commented.Message ID: @.**@.>>
Well, thank you very much for your answer
Zeyue Shen
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