Behavior around signed imm values and 64bit ALU operations

[Alan-Jowett]

Assume:

mov r0, -10

Byte sequence:

b7 00 00 00 f6 f6 ff ff

What value should r0 contain?
0x00000000FFFFFFF6 or 0xFFFFFFFFFFFFFFF6

Should there be a sign extend operation when loading the 32bit immediate value into the 64bit unsigned register?

[yesh0]

According to the Linux interpreter, yes, it should be sign-extended. (And so do all the other ALU64 operations except shifts.)

https://github.com/torvalds/linux/blob/ef4d3ea40565a781c25847e9cb96c1bd9f462bc6/kernel/bpf/core.c#L1734-L1736

ALU64_MOV_K:
    DST = IMM;
//  // or rather
//  regs[insn->dst_reg] = insn->imm;
//  // assigning imm (i32) to regs[...] (u64) does sign-bit extension in c

[Alan-Jowett]

Thanks @yesh0, appreciate the feedback.

We now have a test to measure this behavior on both Linux and other BPF runtimes.

This issue was to add clarity to the doc as I felt it wasn't super clear.