Last release (3.10.0) doesn't support DUTs with CLIC

[marcfedorow]

riscv-arch-test/riscv-test-suite/env/arch_test.h

Line 1169 in cd94912

LI(T4,(1<<(XLEN-1))+(1<<12 - 1<<2)) // make a mask of int bit and cause(11:2). This

Despite the above masking, riscof framework, etc, etc, arch-tests still doesn't seem to support proper testing of c.ebreak and privileged tests yet.
The problem was described here #194, here #285 and even there #440.

To fix this problem, the following patch must be applied to release 3.10.0:

diff --git a/riscv-test-suite/env/arch_test.h b/riscv-test-suite/env/arch_test.h
index aaaaaaaa..bbbbbbbb 100644
--- a/riscv-test-suite/env/arch_test.h
+++ b/riscv-test-suite/env/arch_test.h
@@ -1166,6 +1166,8 @@ common_\__MODE__\()entry:
 //spcl case handling for ECALL in GOTO_MMODE mode,)  ****tests can't use ECALL T2=0****
 spcl_\__MODE__\()2mmode_test:
         csrr    T5, CSR_XCAUSE
+        li      T4, ~0x7fff0000                 // bits reserved for mpp, mpie, etc
+        and     T5, T5, T4                      // clear such bits
         LI(T4,(1<<(XLEN-1))+(1<<12 - 1<<2))     // make a mask of int bit and cause(11:2). This 
         and     T4, T4, T5                      // Keep int bit and cause[11:2]  NOTE: cause 10 is RSVD.  Sail will diverge, but buggy anyway  
         addi    T4, T4, -8                      // map cause 8..11 to 0.  Mmode should avoid ECALL 0
@@ -1224,11 +1226,13 @@ rvtest_\__MODE__\()endtest:                     // target may be too far away, s
 //------end atomic------------------------------------------------
 //  convert mtrap_sigptr to curr_mode trap_sigptr
         LREG    T3, sig_bgn_off+sv_area_off(sp) // load     Mmode sig begin addr
+        andi    T3, T3, -4                      // clear CLIC bits
         sub     T1, T1, T3                      // cvt to offset from sig begin
         LREG    T3, sig_bgn_off+          0(sp) // load <currmode>sig begin addr
         add     T1, T1, T3                      // add offset from sig_begin to curr sig_begin addr
 
         LREG    T3, xtvec_new_off(sp)           // get pointer to actual tramp table
+        andi    T3, T3, -4                      // clear CLIC bits
 //----------------------------------------------------------------
 
   /*************************************************************************/

[allenjbaum]

Whatever the problem really is, this isn't the way to fix this. First, LI() should be used instead of li ( a minor point, but trests may break depending on the toolchain otherwise). Second, that "li" causes bits 30..16 to be cleared. But the existing LI already clears 30..12, and also 1:0, so the effect of those added instructions appear to be ... no effect. I don't quite understand the addition of the "andi" clears the CLIC mode bits, because the register you're clearing contains the address of a save area that is already aligned, So, the effect of that would appear to be ... no effect. Ditto for the second "andi".

…

On Sat, Dec 28, 2024 at 6:46 AM marcfedorow ***@***.***> wrote: https://github.com/riscv-non-isa/riscv-arch-test/blob/cd94912fed2aab75d7d5f115b441da0813fdce8d/riscv-test-suite/env/arch_test.h#L1169 Despite the above masking, riscof framework, etc, etc, arch-tests still doesn't seem to support proper testing of c.ebreak and privileged tests yet. The problem was described here #194 <#194>, here #252 <#252> and even there #440 <#440>. To fix this problem, the following patch must be applied to release 3.10.0: diff --git a/riscv-test-suite/env/arch_test.h b/riscv-test-suite/env/arch_test.h index aaaaaaaa..bbbbbbbb 100644--- a/riscv-test-suite/env/arch_test.h+++ b/riscv-test-suite/env/arch_test.h@@ -1166,6 +1166,8 @@ common_\__MODE__\()entry: //spcl case handling for ECALL in GOTO_MMODE mode,) ****tests can't use ECALL T2=0**** spcl_\__MODE__\()2mmode_test: csrr T5, CSR_XCAUSE+ li T4, ~0x7fff0000 // bits reserved for mpp, mpie, etc+ and T5, T5, T4 // clear such bits LI(T4,(1<<(XLEN-1))+(1<<12 - 1<<2)) // make a mask of int bit and cause(11:2). This and T4, T4, T5 // Keep int bit and cause[11:2] NOTE: cause 10 is RSVD. Sail will diverge, but buggy anyway addi T4, T4, -8 // map cause 8..11 to 0. Mmode should avoid ECALL 0@@ -1224,11 +1226,13 @@ rvtest_\__MODE__\()endtest: // target may be too far away, s //------end atomic------------------------------------------------ // convert mtrap_sigptr to curr_mode trap_sigptr LREG T3, sig_bgn_off+sv_area_off(sp) // load Mmode sig begin addr+ andi T3, T3, -4 // clear CLIC bits sub T1, T1, T3 // cvt to offset from sig begin LREG T3, sig_bgn_off+ 0(sp) // load <currmode>sig begin addr add T1, T1, T3 // add offset from sig_begin to curr sig_begin addr LREG T3, xtvec_new_off(sp) // get pointer to actual tramp table+ andi T3, T3, -4 // clear CLIC bits //---------------------------------------------------------------- /*************************************************************************/ — Reply to this email directly, view it on GitHub <#585>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AHPXVJQXMDWHGA45XWZEGBT2H22VJAVCNFSM6AAAAABUJ3XHGOVHI2DSMVQWIX3LMV43ASLTON2WKOZSG43DCNZUHA3TINI> . You are receiving this because you are subscribed to this thread.Message ID: ***@***.***>

[marcfedorow]

But the existing LI already clears 30..12, and also 1..0

It clears such bits of T4, not T5.
Those bits of T5 are not cleared.
If you clear all of those bits (i.e. 30..12 and 1..0) of T5, signature comparison will be broken (despite no difference between .signature files).

I don't quite understand the addition of the "andi" clears the CLIC mode
bits, because the register you're clearing contains the address of a save
area that is already aligned,

That's probably because you don't quite understand how CLIC works.
If you read CLIC spec, you might see that bits 1..0 are used to indicate CLIC mode (because otherwise they are reserved, i.e. hardwired zero).
So despite the region is aligned, the value contains 0b..11, i.e. lower two bits are set.
Thus, while intension is to jump to the aligned address, actual value is simultaneously "misaligned" and wrong (because of bits that indicate enabled CLIC).
Clearing such bits allows to restore actual address (that is fortunately aligned) and jumping to it.