In-Kernel Lua examples fail because of non-integer key types

[gorgonical]

I know that the JIT bytecode to BPF compiler is practically unmaintained and does not receive much attention, but I am using it currently. Anyway, the kprobe-latency.lua example does not work, yielding this error:

stack traceback:
        /usr/share/luajit-2.1/bpf.lua:1380: in function '__index'
        /usr/share/luajit-2.1/bpf.lua:665: in function 'MAP_INIT'
        /usr/share/luajit-2.1/bpf.lua:705: in function </usr/share/luajit-2.1/bpf.lua:697>
        [C]: in function 'xpcall'
        /usr/share/luajit-2.1/bpf.lua:1383: in function 'compile'
        /usr/share/luajit-2.1/bpf.lua:1500: in function 'kprobe'
        /kprobe-latency.lua:30: in main chunk
        [C]: at 0x5652829fafa0
luajit: /usr/share/luajit-2.1/bpf.lua:1502: attempt to index local 'prog' (a nil value)
stack traceback:
        /usr/share/luajit-2.1/bpf.lua:1502: in function 'kprobe'
        /kprobe-latency.lua:30: in main  #chunk//
        [C]: at 0x5652829fafa0

After careful inspection of the resulting JIT bytecode, I identified the problem (I think). My hypothesis is that the problem lies in probe_read in builtins.lua. Specifically, when the bytecodes for calling the probe_read helper are emitted, the result is placed in the 0 register. After calling, the VM state is updated to reflect that the VM tmpvar is not active. However, I believe the the register that the return value was placed in, in this case 0, should be persisted back to the dst variable. Otherwise, the return value from probe_read is not recorded anywhere in the VM state:

builtins.lua:
builtins[probe_read] = function (e, ret, dst, src, vtype, ofs)
   ...
   e.emit(BPF.JMP + BPF.CALL, 0, 0, 0, HELPER.probe_read)
   -- This updates the VM to locate the destination variable's value in the emitted register.
   e.V[dst].reg = e.V[e.tmpvar].reg 
   --
   e.V[e.tmpvar].reg = nil  -- Free temporary registers

I haven't conclusively tested this because I don't have a thorough mental model of the system, but it does (seem) to fix this error in particular. An inspection of the resulting BPF program seems to yield expected results, too.

Sorry for the messy formatting of the proposed patch. If anyone is interested in this matter I am happy to share more diagnostic information or run tests to confirm this issue.

For context, I am building against kernel version 6.12.27 using Buildroot 25.08 as the build environment, and happy to share my buildroot config to establish a similar environment.