[llvm-bugs] [Bug 38466] New: Miscompilation of non-virtual thunk on x86

[via llvm-bugs]

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

            Bug ID: 38466
           Summary: Miscompilation of non-virtual thunk on x86
           Product: new-bugs
           Version: unspecified
          Hardware: PC
                OS: Linux
            Status: NEW
          Severity: enhancement
          Priority: P
         Component: new bugs
          Assignee: unassignedbugs at nondot.org
          Reporter: mh+llvm at glandium.org
                CC: llvm-bugs at lists.llvm.org

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
https://dxr.mozilla.org/mozilla-central/rev/4e56a2f51ad739ca52046723448f3129a58f1666/netwerk/protocol/http/HttpChannelChild.cpp

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.

-- 
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/20180807/863c98d6/attachment.html>