Re: [PATCH bpf-next] selftests/bpf: Fix some incorrect inline asm codes

[Yonghong Song <yonghong.song@linux.dev>]

On 6/12/25 2:15 PM, Alexei Starovoitov wrote:
> On Thu, Jun 12, 2025 at 12:49 PM Eduard Zingerman <eddyz87@gmail.com> wrote:
>> On Thu, 2025-06-12 at 12:29 -0700, Yonghong Song wrote:
>>
>> [...]
>>
>>>> Warning in llvm/gcc on imm32 > UINT_MAX is not correct either.
>>>> llvm should probably accept 0xffffFFFFdeadbeef as imm32.
>>> In llvm, the value is represented as an int64, we probably
>>> can just check the upper 32bit must be 0 or 0xffffFFFF.
>>> Otherwise, the value is out of range.
>> I agree with Yonghong, supporting things like 0xffffFFFFdeadbeef and
>> rejecting things like 0x8000FFFFdeadbeef would require changes to the
>> assembly parser to behave differently for literals of length 8 (signe
>> extend them) and >8 (zero extend them), which might be surprising in
>> some other ways.
> Ok. So what's the summary?
> No selftest changes needed and we add a check to llvm
> to warn when upper 32 bits !=0 and != 0xffffFFFF ?

I did a little more checking, I think the value range
in [INT_MIN, UINT_MAX] is what we want. This is also my v1 of
llvm patch.

Support we have 64bit value, 0xffffFFFF00000001,
truncating the top 32bit, it becomes 1 and this value 1
won't be able to sign extension properly to 0xffffFFFF00000001.

But for any 64bit value in [INT_MIN, UINT_MAX],
if truncated to 32bit, it can still do proper sign
extenstion to get the original value.