riscv-software-src
GCC 15 + RVV cause illegal instruction sequence in PK
When compiling PK with the latest GCC v15 with architecture RV64GCV the compiler uses vector instructions for uart init before mstatus.VS is properly set which causes illegal instruction error in spike.
See the instruction sequence:
_install/bin/spike --isa=rv64gcv -d pk hello
(spike)
core 0: 0x0000000000001000 (0x00000297) auipc t0, 0x0
(spike)
core 0: 0x0000000000001004 (0x02028593) addi a1, t0, 32
(spike)
core 0: 0x0000000000001008 (0xf1402573) csrr a0, mhartid
(spike)
core 0: 0x000000000000100c (0x0182b283) ld t0, 24(t0)
(spike)
core 0: 0x0000000000001010 (0x00028067) jr t0
(spike)
core 0: >>>> MEM_START
core 0: 0x0000000080000000 (0x1f80006f) j pc + 0x1f8
(spike)
core 0: >>>> do_reset
core 0: 0x00000000800001f8 (0x00000093) li ra, 0
(spike)
core 0: 0x00000000800001fc (0x00000113) li sp, 0
(spike)
core 0: 0x0000000080000200 (0x00000193) li gp, 0
(spike)
core 0: 0x0000000080000204 (0x00000213) li tp, 0
(spike)
core 0: 0x0000000080000208 (0x00000293) li t0, 0
(spike)
core 0: 0x000000008000020c (0x00000313) li t1, 0
(spike)
core 0: 0x0000000080000210 (0x00000393) li t2, 0
(spike)
core 0: 0x0000000080000214 (0x00000413) li s0, 0
(spike)
core 0: 0x0000000080000218 (0x00000493) li s1, 0
(spike)
core 0: 0x000000008000021c (0x00000613) li a2, 0
(spike)
core 0: 0x0000000080000220 (0x00000693) li a3, 0
(spike)
core 0: 0x0000000080000224 (0x00000713) li a4, 0
(spike)
core 0: 0x0000000080000228 (0x00000793) li a5, 0
(spike)
core 0: 0x000000008000022c (0x00000813) li a6, 0
(spike)
core 0: 0x0000000080000230 (0x00000893) li a7, 0
(spike)
core 0: 0x0000000080000234 (0x00000913) li s2, 0
(spike)
core 0: 0x0000000080000238 (0x00000993) li s3, 0
(spike)
core 0: 0x000000008000023c (0x00000a13) li s4, 0
(spike)
core 0: 0x0000000080000240 (0x00000a93) li s5, 0
(spike)
core 0: 0x0000000080000244 (0x00000b13) li s6, 0
(spike)
core 0: 0x0000000080000248 (0x00000b93) li s7, 0
(spike)
core 0: 0x000000008000024c (0x00000c13) li s8, 0
(spike)
core 0: 0x0000000080000250 (0x00000c93) li s9, 0
(spike)
core 0: 0x0000000080000254 (0x00000d13) li s10, 0
(spike)
core 0: 0x0000000080000258 (0x00000d93) li s11, 0
(spike)
core 0: 0x000000008000025c (0x00000e13) li t3, 0
(spike)
core 0: 0x0000000080000260 (0x00000e93) li t4, 0
(spike)
core 0: 0x0000000080000264 (0x00000f13) li t5, 0
(spike)
core 0: 0x0000000080000268 (0x00000f93) li t6, 0
(spike)
core 0: 0x000000008000026c (0x34001073) csrw mscratch, zero
(spike)
core 0: 0x0000000080000270 (0x00000297) auipc t0, 0x0
(spike)
core 0: 0x0000000080000274 (0xd9428293) addi t0, t0, -620
(spike)
core 0: 0x0000000080000278 (0x30529073) csrw mtvec, t0
(spike)
core 0: 0x000000008000027c (0x30502373) csrr t1, mtvec
(spike)
core 0: 0x0000000080000280 (0x00629063) bne t0, t1, pc + 0
(spike)
core 0: 0x0000000080000284 (0x00012117) auipc sp, 0x12
(spike)
core 0: 0x0000000080000288 (0xc3c10113) addi sp, sp, -964
(spike)
core 0: 0x000000008000028c (0xf14026f3) csrr a3, mhartid
(spike)
core 0: 0x0000000080000290 (0x00c69613) slli a2, a3, 12
(spike)
core 0: 0x0000000080000294 (0x00c10133) add sp, sp, a2
(spike)
core 0: 0x0000000080000298 (0x00069463) bnez a3, pc + 8
(spike)
core 0: 0x000000008000029c (0x3da0306f) j pc + 0x33da
(spike)
core 0: >>>> init_first_hart
core 0: 0x0000000080003676 (0x00007179) c.addi16sp sp, -48
(spike)
core 0: 0x0000000080003678 (0x0000852e) c.mv a0, a1
(spike)
core 0: 0x000000008000367a (0x0000f406) c.sdsp ra, 40(sp)
(spike)
core 0: 0x000000008000367c (0x0000f022) c.sdsp s0, 32(sp)
(spike)
core 0: 0x000000008000367e (0x0000ec26) c.sdsp s1, 24(sp)
(spike)
core 0: 0x0000000080003680 (0x00001800) c.addi4spn s0, sp, 48
(spike)
core 0: 0x0000000080003682 (0x0000e84a) c.sdsp s2, 16(sp)
(spike)
core 0: 0x0000000080003684 (0x0000e44e) c.sdsp s3, 8(sp)
(spike)
core 0: 0x0000000080003686 (0x000084ae) c.mv s1, a1
(spike)
core 0: 0x0000000080003688 (0x5fc000ef) jal pc + 0x5fc
(spike)
core 0: >>>> query_uart
core 0: 0x0000000080003c84 (0xcc747057) vsetivli zero, 8, e8, mf2, ta, ma
core 0: exception trap_illegal_instruction, epc 0x0000000080003c84
core 0: tval 0x00000000cc747057
I assume gcc uses vector calling convention now, since compiling with -fno-tree-vectorize does not fix the issue.
The PK make script needs to set proper compiler flags for disabling vectorisation and vector calling convention (which I am not aware of) or needs to set mstatus ASAP before any compiler generated code gets executed.
What I did as a temporary fix in minit.c:
void init_first_hart(uintptr_t hartid, uintptr_t dtb)
{
// set mstatus first
mstatus_init();
// Confirm console as early as possible
query_uart(dtb);
query_uart16550(dtb);
query_uart_litex(dtb);
query_htif(dtb);
...
and removed the line
if (supports_extension('V'))
I think we'll have to avoid compiling with v in the -march string. But if you find a better way, I'm all ears.
I have the same problem with 14.2 gcc riscv64-unknown-elf-gcc (g04696df09) 14.2.0 . query_uart is built with vector instructions but mstatus registers flags are not yet set.
Adding mstatus_init(); at the start of init_first_hart is enough to fix it. Just make sure to run Spike with --isa=rv64gcv so misa register has bit 21 set marking the support for 'V' extension.
diff --git a/machine/minit.c b/machine/minit.c
index 3174409..72f47ef 100644
--- a/machine/minit.c
+++ b/machine/minit.c
@@ -191,6 +191,7 @@ static void wake_harts()
void init_first_hart(uintptr_t hartid, uintptr_t dtb)
{
+ mstatus_init();
// Confirm console as early as possible
query_uart(dtb);
query_uart16550(dtb);
