On Tue, Apr 11, 2017 at 8:48 PM, Nadav Amit <[email protected]> wrote:
> Using the LLVM backend of BPF, I sometimes get the wrong code to be
> generated.
>
> For example, for the following program:
>
> int bpf_prog1(void *ign)
> {
> volatile unsigned long t = 0x8983984739ull;
> return *(unsigned long *)((0xffffffff8fff0002ull) + t);
> }
>
> The generated code is
>
> 0: 18 01 00 00 39 47 98 83 00 00 00 00 89 00 00 00 r1 =
> 590618314553ll
> 2: 7b 1a f8 ff 00 00 00 00 *(u64 *)(r10 - 8) = r1
> 3: 79 a1 f8 ff 00 00 00 00 r1 = *(u64 *)(r10 - 8)
> 4: 79 10 02 00 00 00 00 00 r0 = *(u64 *)(r1 + 2)
> 5: 95 00 00 00 00 00 00 00 exit
>
> The culprit seems to be in the offset check in BPFDAGToDAGISel::SelectAddr()
> ( and BPFDAGToDAGISel::SelectFIAddr() ).
>
> Currently, the check is done using:
>
> if (isInt<32>(CN->getSExtValue()))
>
> When in fact, the offset is 16-bit, so it should be done using:
>
> if (isInt<16>(CN->getSExtValue()))
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
