pulehui wrote:
> > A kernel function will expect the uint to be sign-extended, not
> > zero-extended.
>
> I suspect riscv bpf jit will do sign-extension. @pulehui can confirm. This
> may be true for 32-bit subregisters, but I am not sure whether this is true
> for full register or not.
Sorry for late.
riscv64 will do sign-extension for 'unsigned int' and riscv64 bpf JIT will do
the same. We need to explicitly zero-extend it. But I don't have problems with
‘unsigned int‘ **before this patch**.
```
void bpf_kfunc_call_test4(unsigned int a) __ksym;
int kfunc_call_test4(struct __sk_buff *skb) {
unsigned int a = xxx;
bpf_kfunc_call_test4(a);
}
```
if a = 2147483647(0x7FFFFFFFU, bit 31 is 0), it will be a mov insn. It will be
valid 'unsigned int' in kfunc after sign-extension.
```
0: b7 01 00 00 ff ff ff 7f r1 = 0x7fffffff
1: 85 10 00 00 ff ff ff ff call -0x1
```
but if a = 4294967294(0xFFFFFFFEU, bit 31 is 1), it will be a ld_imm64 insn.
And it also be valid 'unsigned int' in kfunc.
```
0: 18 01 00 00 fe ff ff ff 00 00 00 00 00 00 00 00 r1 = 0xfffffffe ll
2: 85 10 00 00 ff ff ff ff call -0x1
```
But **after this patch**, the two numbers get the same result as before this
patch. I don't see ld_imm64 becoming a mov instruction, as well as explicit
zero extension for 'unsigned int'. Is that expected?
https://github.com/llvm/llvm-project/pull/84874
_______________________________________________
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
