BC_USETS in ARM64 fails gc_mark() assertion

[javierguerragiraldez]

How well tested is BC_USETS in the ARM64 interpreter? I'm getting assertion failures on gc_mark() when setting an upvalue to "". The new value has a .marked value of 0x20 (that is, LJ_GC_FIXED but not LJ_GC_WHITES).

I think the USETS instruction tests if the upvalue is black and the value is white before calling lj_gc_barrieruv(), but if i'm reading it correctly (and i'm nowhere near fluent in ARM assembly), the CARG2 register gets the equivalent of *uv->v, and not &uv->tv.

The GCupval object captured in GDB:

{nextgc = {gcptr64 = 0x7ffe7b7b9ea8}, marked = 0xc8, gct = 0x5b, closed = 0x4c, immutable = 0x7b, {tv = {
      u64 = 0x0, n = 0x0, gcr = {gcptr64 = 0x0}, it64 = 0x0, {i = 0x0, it = 0x0}, ftsz = 0x0, u32 = {lo = 0x0,
      hi = 0x0}}, {prev = {gcptr64 = 0x0}, next = {gcptr64 = 0x420}}}, v = {ptr64 = 0x0}, dhash = 0x100000}

which i think means it's closed, but ->v looks invalid. is it because of the str TMP0, [CARG2] operation? again, this looks to me like would be appropriate if CARG2 had &uv->tv.

[javierguerragiraldez]

a colleage of mine suggests this:

diff --git a/src/vm_arm64.dasc b/src/vm_arm64.dasc
index c55794a6..fb226e35 100644
--- a/src/vm_arm64.dasc
+++ b/src/vm_arm64.dasc
@@ -2780,7 +2780,7 @@ static void build_ins(BuildCtx *ctx, BCOp op, int defop)
     |2:  // Check if string is white and ensure upvalue is closed.
     |  ldrb TMP0w, UPVAL:CARG1->closed
     |    tst TMP1w, #LJ_GC_WHITES      // iswhite(str)
-    |  ccmp TMP0w, #0, #0, ne
+    |  ccmp TMP0w, #0, #4, ne
     |  beq <1
     |  // Crossed a write barrier. Move the barrier forward.
     |  mov CARG1, GL

apparently the check for a closed upvalue wasn't correct.

[MikePall]

Applied.