[llvm-bugs] [Bug 37606] New: BPF target: incorrectly assumes 8byte pointers even for clang -target i386

via llvm-bugs llvm-bugs at lists.llvm.org
Mon May 28 01:42:36 PDT 2018


https://bugs.llvm.org/show_bug.cgi?id=37606

            Bug ID: 37606
           Summary: BPF target: incorrectly assumes 8byte pointers even
                    for clang -target i386
           Product: libraries
           Version: trunk
          Hardware: PC
                OS: Linux
            Status: NEW
          Severity: normal
          Priority: P
         Component: Target Description Classes
          Assignee: unassignedbugs at nondot.org
          Reporter: schaub.johannes at googlemail.com
                CC: llvm-bugs at lists.llvm.org

Created attachment 20345
  --> https://bugs.llvm.org/attachment.cgi?id=20345&action=edit
Using pointers

LLC mistranslates the "Using pointers" attachment example, derived from
linux-kernel-4.9/samples/bpf/

       0:       61 12 18 00 00 00 00 00         r2 = *(u32 *)(r1 + 24)
       1:       61 13 1c 00 00 00 00 00         r3 = *(u32 *)(r1 + 28)
       2:       67 03 00 00 20 00 00 00         r3 <<= 32
       3:       4f 23 00 00 00 00 00 00         r3 |= r2
       4:       07 03 00 00 20 00 00 00         r3 += 32
       5:       bf a1 00 00 00 00 00 00         r1 = r10
       6:       07 01 00 00 f8 ff ff ff         r1 += -8
       7:       b7 02 00 00 04 00 00 00         r2 = 4
       8:       85 00 00 00 04 00 00 00         call 4


Inspection by "pahole" shows that the load-addresses used in the generated BPF
assembly assume the layout of 4.9.0-0.bpo.6-amd64 (8byte pointers, 'dev' is at
offset dec 32) rather than 4.9.0-0.bpo.6-686-pae (32byte pointers, 'dev' at
offset dec 20), as one would expect, because the LLVM-IR was generated by Clang
with "-target i386" and specifies the relevant data sizes as 4 byte rather than
8 byte in the datalayout string

The workaround is more than ugly. Currently it consists of storing pointers as
u32 on the BPF stack and accessing members using "offsetof", which apparently
gets correctly resolved at an earlier stage by clang. 

    #define _MEMBER(TYPE,P,M) (*((typeof(((TYPE*)0)->M)*) (((char*)(P)) +
offsetof(TYPE, M))))

    /* ... */
    dev = (u32)_(_MEMBER(struct sk_buff,skb,dev))

-- 
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-bugs/attachments/20180528/b430d9bc/attachment.html>


More information about the llvm-bugs mailing list