<html>
<head>
<base href="https://bugs.llvm.org/">
</head>
<body><table border="1" cellspacing="0" cellpadding="8">
<tr>
<th>Bug ID</th>
<td><a class="bz_bug_link
bz_status_NEW "
title="NEW - BPF target: incorrectly assumes 8byte pointers even for clang -target i386"
href="https://bugs.llvm.org/show_bug.cgi?id=37606">37606</a>
</td>
</tr>
<tr>
<th>Summary</th>
<td>BPF target: incorrectly assumes 8byte pointers even for clang -target i386
</td>
</tr>
<tr>
<th>Product</th>
<td>libraries
</td>
</tr>
<tr>
<th>Version</th>
<td>trunk
</td>
</tr>
<tr>
<th>Hardware</th>
<td>PC
</td>
</tr>
<tr>
<th>OS</th>
<td>Linux
</td>
</tr>
<tr>
<th>Status</th>
<td>NEW
</td>
</tr>
<tr>
<th>Severity</th>
<td>normal
</td>
</tr>
<tr>
<th>Priority</th>
<td>P
</td>
</tr>
<tr>
<th>Component</th>
<td>Target Description Classes
</td>
</tr>
<tr>
<th>Assignee</th>
<td>unassignedbugs@nondot.org
</td>
</tr>
<tr>
<th>Reporter</th>
<td>schaub.johannes@googlemail.com
</td>
</tr>
<tr>
<th>CC</th>
<td>llvm-bugs@lists.llvm.org
</td>
</tr></table>
<p>
<div>
<pre>Created <span class=""><a href="attachment.cgi?id=20345" name="attach_20345" title="Using pointers">attachment 20345</a> <a href="attachment.cgi?id=20345&action=edit" title="Using pointers">[details]</a></span>
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))</pre>
</div>
</p>
<hr>
<span>You are receiving this mail because:</span>
<ul>
<li>You are on the CC list for the bug.</li>
</ul>
</body>
</html>