<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 - Miscompilation of non-virtual thunk on x86"
href="https://bugs.llvm.org/show_bug.cgi?id=38466">38466</a>
</td>
</tr>
<tr>
<th>Summary</th>
<td>Miscompilation of non-virtual thunk on x86
</td>
</tr>
<tr>
<th>Product</th>
<td>new-bugs
</td>
</tr>
<tr>
<th>Version</th>
<td>unspecified
</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>enhancement
</td>
</tr>
<tr>
<th>Priority</th>
<td>P
</td>
</tr>
<tr>
<th>Component</th>
<td>new bugs
</td>
</tr>
<tr>
<th>Assignee</th>
<td>unassignedbugs@nondot.org
</td>
</tr>
<tr>
<th>Reporter</th>
<td>mh+llvm@glandium.org
</td>
</tr>
<tr>
<th>CC</th>
<td>llvm-bugs@lists.llvm.org
</td>
</tr></table>
<p>
<div>
<pre>The miscompilation happens in the non-virtual thunk to to
mozilla::net::HttpChannelChild::AsyncCall(void
(mozilla::net::HttpChannelChild::*)(),
nsRunnableMethod<mozilla::net::HttpChannelChild, void, true,
(mozilla::RunnableKind)0>**) when compiling
<a href="https://dxr.mozilla.org/mozilla-central/rev/4e56a2f51ad739ca52046723448f3129a58f1666/netwerk/protocol/http/HttpChannelChild.cpp">https://dxr.mozilla.org/mozilla-central/rev/4e56a2f51ad739ca52046723448f3129a58f1666/netwerk/protocol/http/HttpChannelChild.cpp</a>
I'd attach the original preprocessed file, but it's too large for bugzilla.
I've been able to reproduce the problem with clang 6 and current clang trunk
(r339085).
The thunk looks like:
00991a46
<_ZThn1092_N7mozilla3net16HttpChannelChild9AsyncCallEMS1_FvvEPP16nsRunnableMethodIS1_vLb1ELNS_12RunnableKindE0EE>:
991a46: 55 push %ebp
991a47: 89 e5 mov %esp,%ebp
991a49: 53 push %ebx
991a4a: 83 ec 24 sub $0x24,%esp
991a4d: b9 bc fb ff ff mov $0xfffffbbc,%ecx
991a52: f2 0f 10 45 f0 movsd -0x10(%ebp),%xmm0
991a57: 8b 45 14 mov 0x14(%ebp),%eax
991a5a: e8 00 00 00 00 call 991a5f
<_ZThn1092_N7mozilla3net16HttpChannelChild9AsyncCallEMS1_FvvEPP16nsRunnableMethodIS1_vLb1ELNS_12RunnableKindE0EE+0x19>
991a5f: 5b pop %ebx
991a60: 03 4d 08 add 0x8(%ebp),%ecx
991a63: 81 c3 a1 65 01 06 add $0x60165a1,%ebx
991a69: f2 0f 11 44 24 04 movsd %xmm0,0x4(%esp)
991a6f: 89 44 24 0c mov %eax,0xc(%esp)
991a73: 89 0c 24 mov %ecx,(%esp)
991a76: e8 bf ba ff ff call 98d53a
<_ZN7mozilla3net16HttpChannelChild9AsyncCallEMS1_FvvEPP16nsRunnableMethodIS1_vLb1ELNS_12RunnableKindE0EE>
991a7b: 83 c4 24 add $0x24,%esp
991a7e: 5b pop %ebx
991a7f: 5d pop %ebp
991a80: c3 ret
991a81: 90 nop
Note how it's filling %xmm0 from the uninitialized stack, to pass its content
to the actual AsyncCall function, instead of reading the arguments that were
passed in. The result is that the AsyncCall function is passed broken
arguments.
I'm running the code through creduce, hopefully this will yield a small enough
testcase to attach.
Interestingly, the bug goes away if I make the virtual AsyncCall call a
non-virtual AsyncCallImpl method. A thunk is created, which looks similar, but
it reads arguments properly, albeit unefficiently:
00994de0
<_ZThn1092_N7mozilla3net16HttpChannelChild9AsyncCallEMS1_FvvEPP16nsRunnableMethodIS1_vLb1ELNS_12RunnableKindE0EE>:
994de0: 55 push %ebp
994de1: 89 e5 mov %esp,%ebp
994de3: 53 push %ebx
994de4: 56 push %esi
994de5: 83 ec 20 sub $0x20,%esp
994de8: 8b 4d 0c mov 0xc(%ebp),%ecx
994deb: 8b 55 10 mov 0x10(%ebp),%edx
994dee: be bc fb ff ff mov $0xfffffbbc,%esi
994df3: 8b 45 14 mov 0x14(%ebp),%eax
994df6: e8 00 00 00 00 call 994dfb
<_ZThn1092_N7mozilla3net16HttpChannelChild9AsyncCallEMS1_FvvEPP16nsRunnableMethodIS1_vLb1ELNS_12RunnableKindE0EE+0x1b>
994dfb: 5b pop %ebx
994dfc: 03 75 08 add 0x8(%ebp),%esi
994dff: 81 c3 05 82 01 06 add $0x6018205,%ebx
994e05: 89 4d f0 mov %ecx,-0x10(%ebp)
994e08: 89 55 f4 mov %edx,-0xc(%ebp)
994e0b: f2 0f 10 45 f0 movsd -0x10(%ebp),%xmm0
994e10: f2 0f 11 44 24 04 movsd %xmm0,0x4(%esp)
994e16: 89 44 24 0c mov %eax,0xc(%esp)
994e1a: 89 34 24 mov %esi,(%esp)
994e1d: e8 96 eb ff ff call 9939b8
<_ZN7mozilla3net16HttpChannelChild13AsyncCallImplEMS1_FvvEPP16nsRunnableMethodIS1_vLb1ELNS_12RunnableKindE0EE>
994e22: 83 c4 20 add $0x20,%esp
994e25: 5e pop %esi
994e26: 5b pop %ebx
994e27: 5d pop %ebp
994e28: c3 ret
994e29: 90 nop
Note the pasted assembly was generated with -Os -fno-omit-frame-pointer, but
this happens equally with -O2 and without -fno-omit-frame-pointer. It also
happens with -fno-sse.</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>