Thanks for your quick response.
I don’t know how you got the trace from llvm trunk, but it seems the trunk is
buggy as well. As you can see in the following line
> r0 = *(u64 *)(r1 - 1879113726)
This offset cannot fit within 16-bit. Check how this instruction is encoded
and you will see it is wrong (I checked with the trunk).
Note that after the fix, an add instruction is added.
The generated code is then:
bpf_prog1:
; {
0: 18 01 00 00 39 47 98 83 00 00 00 00 89 00 00 00 r1 =
590618314553ll
; volatile unsigned long t = 0x8983984739ull;
2: 7b 1a f8 ff 00 00 00 00 *(u64 *)(r10 - 8) = r1
; return *(unsigned long *)((0xffffffff8fff0002ull) + t);
3: 79 a1 f8 ff 00 00 00 00 r1 = *(u64 *)(r10 - 8)
4: 07 01 00 00 02 00 ff 8f r1 += -1879113726
5: 79 10 00 00 00 00 00 00 r0 = *(u64 *)(r1 + 0)
6: 95 00 00 00 00 00 00 00 exit
I sent a patch to https://reviews.llvm.org/D32055 .
I do not know the LLVM test-suite, so please prepare a test based on the
example and the bug-fix.
Thanks,
Nadav
> On Apr 12, 2017, at 7:30 PM, Alexei Starovoitov
> <[email protected]> wrote:
>
> thanks!
> that does look like a bug and the fix makes sense, but I cannot
> reproduce the issue.
> On latest llvm trunk I see:
> r1 = 590618314553ll
> *(u64 *)(r10 - 8) = r1
> r1 = *(u64 *)(r10 - 8)
> r0 = *(u64 *)(r1 - 1879113726)
> which is correct.
> Could you prepare a patch with test cases that fails/passes before/after
> on the latest trunk?
>
> Thanks a bunch!
_______________________________________________
iovisor-dev mailing list
[email protected]
https://lists.iovisor.org/mailman/listinfo/iovisor-dev
