[Bug gold/26678] construction vtable defined in a discarded section

[ccoutant at gmail dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=26678

Cary Coutant <ccoutant at gmail dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |RESOLVED
         Resolution|---                         |NOTABUG

--- Comment #1 from Cary Coutant <ccoutant at gmail dot com> ---
This appears to be a bug in GCC, but the inline asm, being outside the ABI,
could simply render this an unfortunate incompatibility between GCC and Clang.

The problem is that the inline asm is making GCC think that ~A::A() can
raise an exception, so it creates compensation code in D::D(), which
requires a construction vtable for B-in-C, which gets added to the COMDAT
group that also contains the vtable for C (_ZV1C).

Here's the code GCC generates for D::D(), from a.o:

0000000000000002 <_ZN1DC1E1C>:
   2:   48 83 ec 18             sub    $0x18,%rsp
   6:   48 8b 06                mov    (%rsi),%rax
   9:   48 8b 40 e8             mov    -0x18(%rax),%rax
   d:   8b 04 06                mov    (%rsi,%rax,1),%eax
  10:   89 44 24 08             mov    %eax,0x8(%rsp)
  14:   48 8b 05 00 00 00 00    mov    0x0(%rip),%rax        # 1b
<_ZN1DC1E1C+0x19>
                        17: R_X86_64_REX_GOTPCRELX      _ZTV1C-0x4
  1b:   48 8d 40 18             lea    0x18(%rax),%rax
  1f:   48 89 04 24             mov    %rax,(%rsp)
  23:   48 89 e7                mov    %rsp,%rdi
  26:   e8 00 00 00 00          callq  2b <_ZN1DC1E1C+0x29>
                        27: R_X86_64_PLT32      _Z1f1C-0x4
  2b:   eb 17                   jmp    44 <_ZN1DC1E1C+0x42>
  2d:   48 89 c7                mov    %rax,%rdi
  30:   48 8d 05 00 00 00 00    lea    0x0(%rip),%rax        # 37
<_ZN1DC1E1C+0x35>
                        33: R_X86_64_PC32       _ZTC1C0_1B+0x14
  37:   48 89 04 24             mov    %rax,(%rsp)
  3b:   89 44 24 08             mov    %eax,0x8(%rsp)
  3f:   e8 00 00 00 00          callq  44 <_ZN1DC1E1C+0x42>
                        40: R_X86_64_PLT32      _Unwind_Resume-0x4
  44:   48 83 c4 18             add    $0x18,%rsp
  48:   c3                      retq   

The code from offset 0x2d through the callq at 0x3f is the compensation code
generated if an exception happens during the call of f(c). Without that inline
asm, GCC would have generated the same code as clang, with no compensation code
and no construction vtable necessary.

Compile with --no-exceptions, and the problem also goes away.

I see the same problem whether compiling a.cpp at -O0, -O1, -O2, or -O3.

At least GCC is consistent when compiling a.cpp and main.cpp, so it could
be argued that this case simply isn't covered by the C++ ABI, and GCC and
Clang are free to treat it differently. I made some trivial attempts to
reproduce with something other than inline asm, but could not.

As for why you're getting an error from gold, but not from bfd or lld,
gold is reporting what could have been a real error, though in this
particular case, since an exception could never have been thrown,
the compensation code would never have executed. But when you link with
bfd ld or lld, the lea instruction at 0x2d is left unrelocated, with no
warning, and the program could conceivably crash in the case of an
exception being thrown during the call to f().

-- 
You are receiving this mail because:
You are on the CC list for the bug.