Unexpected Behaviors when Using RISC-V Extension "zbs"

[Coekjan]

Description & Investigation

I tried to run python3.12 on box64, and it crashed with SIGSEGV. Using BOX64_DYNAREC_TEST=1, I saw many differences about RIP:

Warning, difference between x64 Interpreter and Dynarec in 0x3f001e44b1 (0f 82 82 03 00 00 8d b0)
=======================================
DIFF: Dynarec |  Interpreter
----------------------
RIP: 0000003f001e44b7 | 0000003f001e4839
Warning, difference between x64 Interpreter and Dynarec in 0x3f001e4405 (0f 82 2d 01 00 00 83 ea)
=======================================
DIFF: Dynarec |  Interpreter
----------------------
RIP: 0000003f001e440b | 0000003f001e4538
Warning, difference between x64 Interpreter and Dynarec in 0x3f002683c7 (72 2b 2d 00 01 00 00 83)
=======================================
DIFF: Dynarec |  Interpreter
(( omitted ))

These addresses are all in libpython3.12.so and objdump told me they all almost look like:

bt     %eax,%ecx
jb     (( somewhere ))

The bt instruction should set the CF flag and the behavior of the following jb instruction depends on it. So I read current code:

box64/src/dynarec/rv64/dynarec_rv64_0f.c

Lines 1720 to 1739 in d6b9fd2

	case 0xA3:
	INST_NAME("BT Ed, Gd");
	SETFLAGS(X_CF, SF_SUBSET);
	SET_DFNONE();
	nextop = F8;
	GETGD;
	if (MODREG) {
	ed = xRAX + (nextop & 7) + (rex.b << 3);
	} else {
	SMREAD();
	addr = geted(dyn, addr, ninst, nextop, &wback, x3, x1, &fixedaddress, rex, NULL, 1, 0);
	SRAIxw(x1, gd, 5 + rex.w); // r1 = (gd>>5)
	ADDSL(x3, wback, x1, 2 + rex.w, x1);
	LDxw(x1, x3, fixedaddress);
	ed = x1;
	}
	BEXT(x4, ed, gd, x2);
	ANDI(xFlags, xFlags, ~1); // F_CF is 1
	OR(xFlags, xFlags, x4);
	break;

and saw BEXT will emit to bext instruction when "zbs" extension enabled.

---

When turning off the "zbs" extension, libpython3.12 still crashed but the test log showed other differences irrelative with bt instruction:

(( BEGIN ))
Warning, difference between x64 Interpreter and Dynarec in 0x3f001ea3f3 (7e 17 83 fe 63 7f 12 89)
=======================================
DIFF: Dynarec |  Interpreter
----------------------
RIP: 0000003f001ea40c | 0000003f001ea3f5
Warning, difference between x64 Interpreter and Dynarec in 0x3f001ea36f (0f 8f bb 00 00 00 39 c3)
=======================================
DIFF: Dynarec |  Interpreter
----------------------
RIP: 0000003f001ea430 | 0000003f001ea375
Warning, difference between x64 Interpreter and Dynarec in 0x3f001ea3f3 (7e 17 83 fe 63 7f 12 89)
=======================================
DIFF: Dynarec |  Interpreter
----------------------
RIP: 0000003f001ea40c | 0000003f001ea3f5
Warning, difference between x64 Interpreter and Dynarec in 0x3f001ea36f (0f 8f bb 00 00 00 39 c3)
=======================================
DIFF: Dynarec |  Interpreter
----------------------
RIP: 0000003f001ea430 | 0000003f001ea375
(( END ))

Again, objdump told me they all look like:

cmp    (( %esi or $0x63 here )),%eax
jle/jg    (( somewhere ))

---

Maybe at least we can say the bt instruction with "zbs" extension results in the my first "dynarec test" difference of this issue. And the latter one is still in investigation.

[ksco]

There is an undocumented option BOX64_DYNAREC_RV64NOEXT, set this to 1 to disable all the extensions that are not hard requirements for box64 to run.