PPC soft-float: fix ipairs() returning corrupted values and pairs() yielding a spurious nil

[BKPepe]

Two independent bugs in src/vm_ppc.dasc, both confined to the .if not FPU branch and both introduced by 2763a42 ("Patch for PPC64 support"). Upstream LuaJIT is not affected — on the same board, the distro's upstream LuaJIT returns the correct results.

Reproducers on Turris 1.x (e500v2, 32-bit big-endian, musl, soft-float):

local sum = 0
for _, v in ipairs({10, 20, 30}) do
    sum = sum + v
end
assert(sum == 60)

local expected = {7, 8, 9}
local i = 0
for k, v in pairs(expected) do
    i = i + 1
    assert(k == i and v == expected[i])
end
assert(i == 3)

Before the fixes, the ipairs() test yields -42 instead of 60 and the pairs() test sees an extra (nil, nil) iteration. With the fixes, both pass, with and without the JIT.

ipairs() also has a memory-safety angle: only the payload half of the TValue is wrong while the itype stays correct, so for GC-typed elements the type tag ends up in the GCref and tostring() dereferences a fabricated pointer.

Verified on hardware, and through the OpenWrt package build in openwrt/packages#30280, where the resulting powerpc_8548 package was installed on the device and behaves correctly.

[Copilot]

Copilot was unable to review this pull request because the user who requested the review has reached their quota limit.

[BKPepe]

@zhuizhuhaomeng Can you take a look, please?

[zhuizhuhaomeng]

[P1] PPC32LE soft-float ipairs() values are corrupted — src/vm_ppc.dasc (line 1836)
On little-endian PPC, the preceding raw offset-0 load already reads WORD_LO. The changed line reads WORD_LO again, so both registers contain the payload. The subsequent stores write the payload into the type word, producing malformed TValues for ordinary inputs such as ipairs({10, 20}). The load and stores need consistent endian-aware high/low-word handling.

[P2] pairs() checks the payload instead of the type on PPC32LE soft-float — src/vm_ppc.dasc (line 5813)
CARG1 comes from raw offset 0, which is the payload on little-endian systems; CARG2 holds the type. Consequently, the hash-less-table bug remains, while a valid hash value of integer -1 is mistaken for nil and skipped. The check should select the endian-correct register or explicitly load WORD_HI.

Would you please check the review issues from AI?

[BKPepe]

Thanks. Both of these come from 2763a42, and looking again the right fix in each case is to restore what that commit replaced.

For ipairs, the line was lwz TMP3, 4(TMP1) before 2763a42 and became lwz TMP3, WORD_HI(TMP1). The raw offset was correct on both endiannesses, because the stores at 1865-1866 put the two words back at the same offsets. WORD_HI is 0 on big-endian, which is what corrupts the value there. My WORD_LO version fixes big-endian but is not right on little-endian, so restoring 4(TMP1) is the better fix.

For BC_ITERN, 2763a42 removed the shared lwzx RB, TMP2, TMP3 and moved an equivalent load inside the FPU branch only, so on the soft-float path RB still holds the RC*8 left by slwi RB, RC, 3 at 5899 and the check can never match on any endianness. Rather than choose a register per endianness, the soft-float branch should load RB as well, with lwz RB, WORD_HI(CARG3), leaving checknil RB untouched.

That makes both hunks correct on either endianness. I will respin the PR accordingly. I can still only test on big-endian e500v2.