Bug 39578 - Linkage broken for dllimport vtables
Summary: Linkage broken for dllimport vtables
Status: RESOLVED FIXED
Alias: None
Product: gcc
Classification: Unclassified
Component: target (show other bugs)
Version: 4.3.3
: P3 normal
Target Milestone: ---
Assignee: Not yet assigned to anyone
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2009-03-29 15:27 UTC by John E. / TDM
Modified: 2013-12-18 00:50 UTC (History)
4 users (show)

See Also:
Host: mingw32
Target: mingw32
Build: mingw32
Known to work:
Known to fail:
Last reconfirmed:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description John E. / TDM 2009-03-29 15:27:55 UTC
The linkage for the vtable for any class marked dllimport is generated as a standard external link rather than a dllimport "__imp_" link. This results in linker diagnostics such as:

Info: resolving vtable for TestObject by linking to __imp___ZTV10TestObject (auto-import)
d:/jsupport/mingw/bin/../lib/gcc/mingw32/4.3.3-dw2/../../../../mingw32/bin/ld.exe: warning: auto-importing has been activated without --enable-auto-import specified on the command line.
This should work unless it involves constant data structures referencing symbols from auto-imported DLLs.

The following simple testcase demonstrates this.

----- vttest.cpp -----
struct __attribute__((dllimport)) TestObject
{
	virtual void VirtFunc();
};
int main()
{
	TestObject obj;
	obj.VirtFunc();
	return 0;
}

----- vttestdll.cpp -----
struct __attribute__((dllexport)) TestObject
{
	virtual void VirtFunc() {}
};

> g++ -shared -o vttest.dll -Wl,--out-implib,libvttest.dll.a vttestdll.cpp
Creating library file: libvttest.a
> g++ -o vttest.exe vttest.cpp libvttest.dll.a
Info: resolving vtable for TestObject by linking to __imp___ZTV10TestObject (auto-import)
d:/jsupport/mingw/bin/../lib/gcc/mingw32/4.3.3-dw2/../../../../mingw32/bin/ld.exe: warning: auto-importing has been activated without --enable-auto-import specified on the command line.
This should work unless it involves constant data structures referencing symbols from auto-imported DLLs.
Comment 1 Dave Korn 2009-03-29 17:47:07 UTC
For Cygwin, we just recently made --enable-auto-import the default in CVS binutils.  Now that we're moving to shared library runtimes throughout it made sense.

However, I think this is a real bug, as it doesn't happen on 4.3.2; we get a direct undefined reference to the import symbol in the object file:

$ g++ -g -o vttest.exe vttest.cpp libvttest.dll.a --save-temps

admin@ubik /tmp/vttest
$ nm vttest.o
00000000 b .bss
00000000 d .data
00000000 N .debug_abbrev
00000000 N .debug_aranges
00000000 N .debug_frame
00000000 N .debug_info
00000000 N .debug_line
00000000 N .debug_loc
00000000 N .debug_pubnames
00000000 N .debug_ranges
00000000 N .debug_str
00000000 d .eh_frame
00000000 t .text
00000000 t .text$_ZN10TestObjectC1Ev
00000000 T __ZN10TestObjectC1Ev
         U ___gxx_personality_v0
         U ___main
         U __imp___ZN10TestObject8VirtFuncEv
         U __imp___ZTV10TestObject
00000000 T _main

admin@ubik /tmp/vttest
$ 

My earlier build of 4.3.3 with the patch for PR36654 reverted does the same thing.  However, as soon as I reapplied the patch and rebuilt cc1plus, I got this output:

/tmp/vttest $ nm vttest.o    libvtt
00000000 b .bss
00000000 d .data
00000000 N .debug_abbrev
00000000 N .debug_aranges
00000000 N .debug_frame
00000000 N .debug_info
00000000 N .debug_line
00000000 N .debug_loc
00000000 N .debug_pubnames
00000000 N .debug_ranges
00000000 N .debug_str
00000000 d .eh_frame
00000000 t .text
00000000 t .text$_ZN10TestObjectC1Ev
00000000 T __ZN10TestObjectC1Ev
         U __ZTV10TestObject
         U ___gxx_personality_v0
         U ___main
         U __imp___ZN10TestObject8VirtFuncEv
00000000 T _main
/tmp/vttest $

So I think that confirms it.
Comment 2 Kai Tietz 2009-09-12 09:54:04 UTC
I tested this bug for 4.5 and here it seems to be solved for i686-pc-mingw32.
Comment 3 Kai Tietz 2013-12-17 20:09:19 UTC
I retested issue for all open branches.  I can't reproduce issue anymore.  Import library contains symbol for virtual.

If issue still exists please provide a testcase demonstrating that issue for maintained branches still exists.
Comment 4 John E. / TDM 2013-12-18 00:50:18 UTC
I can confirm this has been fixed. Sorry for not doing so sooner.