ISA cases stuck when test rv64ua-v-amoadd_d

[Xxfore]

When run make run under isa folder , it stuck in below case:
spike --isa=rv64gc_zfh_zicboz_svnapot --misaligned rv64ua-v-amoadd_d 2> rv64ua-v-amoadd_d.out

Could someone kindness help about it?

thanks a lot.

[Andrew Waterman]

I can't replicate this with the most recent version of Spike and the most recent version of this repo.

[Xxfore]

I can't replicate this with the most recent version of Spike and the most recent version of this repo.

the version of this repo which i use : master branch (2e782c5)
spike (Spike RISC-V ISA Simulator 1.1.1-dev) : master branch (2e782c5)

How about your version about these repos?
thx.

[Andrew Waterman]

Since you raised the issue, can you try it on the most recent versions of both? (We don’t do backports, so you’ll need to upgrade to take advantage of patches, anyway.)

[Xxfore]

Since you raised the issue, can you try it on the most recent versions of both? (We don’t do backports, so you’ll need to upgrade to take advantage of patches, anyway.)

Actually, i use the newest version to build spike and isa cases of riscv-tests,
So i hope to get your version which works well.

By the way , there's a typo in my above comment, spike version is (0d1a48c0c0e97521c0081b130e97b1352f27380a)

[Xxfore]

Since you raised the issue, can you try it on the most recent versions of both? (We don’t do backports, so you’ll need to upgrade to take advantage of patches, anyway.)

Addtionally, could you help to provide your rv64ua-v-amoadd_d.dump file, i wanna to check if it related toolchain version.

[Andrew Waterman]

Using the Spike commit you mentioned works just fine for me.

My rv64ua-v-amoadd_d.dump is attached.

Unfortunately, we can't provide any further support on this issue. We'll close this ticket in a few days, even if it isn't resolved.

rv64ua-v-amoadd_d.dump.gz

[Xxfore]

Using the Spike commit you mentioned works just fine for me.

My rv64ua-v-amoadd_d.dump is attached.

Unfortunately, we can't provide any further support on this issue. We'll close this ticket in a few days, even if it isn't resolved.

rv64ua-v-amoadd_d.dump.gz

Thanks a lot for your kindness help.

Other u mode cases which enable virtual memory seems work well for me, such as rv64ud-v-move. Only atomic related cases stuck at the end of the case.

core 0: 0xffffffffffe022a0 (0x00073783) ld a5, 0(a4)
core 0: 0xffffffffffe022a4 (0x00078a63) beqz a5, pc + 20
core 0: 0xffffffffffe022b8 (0x00a73023) sd a0, 0(a4)
core 0: 0xffffffffffe022bc (0x0000006f) j pc + 0x0

Anyway ,
I will check more details and update comment if find any useful information.
thank you all the same.

[Xxfore]

Using the Spike commit you mentioned works just fine for me.

My rv64ua-v-amoadd_d.dump is attached.

Unfortunately, we can't provide any further support on this issue. We'll close this ticket in a few days, even if it isn't resolved.

rv64ua-v-amoadd_d.dump.gz

Update:

GCC: gcc version 12.2.0 (g2ee5e430018) which build from "riscv-collab/riscv-gnu-toolchain"
SPIKE : 1.1.1-dev (0d1a48c0c0e9) which build from "riscv-software-src/riscv-isa-sim"
riscv-tests : (2e782c5) which build from "riscv-software-src/riscv-tests"
Necessary files ( spike log and dump ) has attached in attachment.
rv64ua-v-amoadd_d.log
rv64ua-v-amoadd_d.dump.txt

As debug by using command "spike --isa=rv64gc_zfh_zicboz_svnapot -d --misaligned rv64ua-v-amoadd_d" to check if to_host has been set to 1 as normal.

1. breakpoint to 0xffffffffffe027b4 and check a0 is 0 .
   (spike) until pc 0 0xffffffffffe027b4
   (spike) reg 0
   zero: 0x0000000000000000 ra: 0xffffffffffe02740 sp: 0xffffffffffe08e68 gp: 0x0000000000000005
   tp: 0x0000000000000000 t0: 0x0000000000000008 t1: 0x0000000000000000 t2: 0xffffffff7ffff000
   s0: 0xffffffffffe08000 s1: 0x000000000003f000 a0: 0x0000000000000000 a1: 0x0000000000002a20
   a2: 0x0000000000008000 a3: 0x0000000000009000 a4: 0x0000000000000000 a5: 0x0000000000001000
   a6: 0x0000000000000000 a7: 0x0000000000000000 s2: 0x00000000000003e0 s3: 0x0000000000000080
   s4: 0xffffffffffe08008 s5: 0xffffffffffe03000 s6: 0x000000000003f000 s7: 0xffffffffffe08010
   s8: 0xffffffffffe00000 s9: 0x0000000000040000 s10: 0xffffffffffe04000 s11: 0x8000000200006000
   t3: 0x0000000000000000 t4: 0x0000000000000000 t5: 0x0000000000000000 t6: 0x0000000000000000

2. restart and make breakpoint after ecall occur , we can see a0 is 1
   (spike) until pc 0 0x0000000000002a90
   (spike) until pc 0 0xffffffffffe00144
   (spike) reg 0
   zero: 0x0000000000000000 ra: 0x0000000000000000 sp: 0x0000000000000000 gp: 0x0000000000000005
   tp: 0x0000000000000000 t0: 0x0000000000000000 t1: 0x0000000000000000 t2: 0xffffffff7ffff000
   s0: 0x0000000000000000 s1: 0x0000000000000000 a0: 0x0000000000000001 a1: 0xfffffffffffff800
   a2: 0x0000000000000000 a3: 0x0000000000008000 a4: 0xffffffff7ffff800 a5: 0xffffffff7ffff000
   a6: 0x0000000000000000 a7: 0x0000000000000000 s2: 0x0000000000000000 s3: 0x0000000000000000
   s4: 0x0000000000000000 s5: 0x0000000000000000 s6: 0x0000000000000000 s7: 0x0000000000000000
   s8: 0x0000000000000000 s9: 0x0000000000000000 s10: 0x0000000000000000 s11: 0x0000000000000000
   t3: 0x0000000000000000 t4: 0x0000000000000000 t5: 0x0000000000000000 t6: 0x0000000000000000

3. So that we can observe mem address of 8(sp) to monitor when it change to 0 after ecall occur
   (spike) until mem 0 0xffffffffffe08e70 0
   (spike) pc
   Bad or missing arguments for command pc
   (spike) pc 0
   0xffffffffffe02778
   (spike) reg 0
   zero: 0x0000000000000000 ra: 0xffffffffffe02740 sp: 0xffffffffffe08e68 gp: 0x0000000000000005
   tp: 0x0000000000000000 t0: 0x0000000000000008 t1: 0x0000000000000000 t2: 0xffffffff7ffff000
   s0: 0xffffffffffe08000 s1: 0x0000000000008000 a0: 0x0000000000000000 a1: 0x0000000000000000
   a2: 0x0000000000000000 a3: 0x0000000000009000 a4: 0x0000000000008e60 a5: 0xffffffffffe08e60
   a6: 0xffffffffffe025ec a7: 0x0000000000000000 s2: 0x0000000000000080 s3: 0x0000000000000080
   s4: 0xffffffffffe08008 s5: 0xffffffffffe03000 s6: 0x000000000003f000 s7: 0xffffffffffe08010
   s8: 0xffffffffffe00000 s9: 0x0000000000040000 s10: 0xffffffffffe04000 s11: 0x8000000200006000
   t3: 0x0000000000000000 t4: 0x0000000000000000 t5: 0x0000000000000000 t6: 0x0000000000000000

8132 core 0: 0xffffffffffe02774 (0x00b7b823) sd a1, 16(a5)
8133 core 0: 0xffffffffffe02778 (0x00c7bc23) sd a2, 24(a5)

We can see that 8(sp) value has been overwrite by run
0xffffffffffe02774 (0x00b7b823) sd a1, 16(a5)

So that the case will stuck at the end.

I found 2 ways to pass the case :

1. Use older GCC toolchain, I get nuclei GCC toolchain( gcc version 10.2.0) in local , build and run all tests pass.
2. modify STACK_TOP in env/v/entry.S like below , it will also pass.

diff --git a/v/entry.S b/v/entry.S
index 49b2d3e..8bf0743 100644
--- a/v/entry.S
+++ b/v/entry.S
@@ -10,7 +10,7 @@
 # define REGBYTES 4
 #endif
 
-#define STACK_TOP (_end + 4096)
+#define STACK_TOP (_end + 4096 * 2)

Finally, because im not familar in Toolchain, i cant find out which modification of toolchain cause different compile result so that atomic related case failed.
Anyway, this issue should be close , I will raise issue on Toolchain Repo if needed.

Thanks .

[Andrew Waterman]

Thank you for investigating this. I had not realized the stack was so small.