This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: Workaround for virtual function/dllimport bug, also patch guidance request
- To: Jason Merrill <jason at cygnus dot com>
- Subject: Re: Workaround for virtual function/dllimport bug, also patch guidance request
- From: Mumit Khan <khan at nanotech dot wisc dot edu>
- Date: Sun, 28 Nov 1999 01:01:01 -0600
- cc: geoff schmidt <gschmidt at MIT dot EDU>, gcc at gcc dot gnu dot org
Jason Merrill <jason@cygnus.com> writes:
> Again I ask, how does MS handle this situation?
>
Ah, sorry about that. Here're the various rules gleaned from docs and
generated assembly:
dllexport an entire class:
- all members, including static data, are exported.
- vtable: Emit linkonce vtables using as yet unknown heuristic. However,
it seems to be using a heuristic similar to GCC.
- inline methods: Emit linkonce out-of-line copy.
- non-inline methods: Must provide definition somewhere, since the DLL
must contain the definition that the DLL clients can reference.
dllimport an entire class:
- vtable: Never emit vtables for imported functions, but assume imported
from DLL. MSVC doesn't have direct equiv of pragma interface/
implementation, so there's a potential for missing vtable when using
GCC for dllimported classes for code that makes extensive use of
these pragma's.
For subclasses of dllimported functions, vtables reference the
*thunk* functions, not the synthetically created indirect references
(by backend in i386_pe_mark_dllimport); this is needed to allow
taking the address of the virtual function. This is one thing that
needs to be changed in current GCC implementation (eg., by
nullifying the dllimport attribute of virtual functions in the
backend, or dealing with specifically in the front-end).
- inline methods: Inline copies can be expanded, but never
instantiated. Addresses of inline methods resolve to the linkonce
out-of-line one in the DLL.
The easiest way is obviously to tell GCC not to "import" functions, just
import data. This can be done with -mnop-fun-dllimport option, but this
adds the overhead for the indirect reference in the thunk functions. A
better method, if we can't touch front-ends, is to mark certain class
of methods (such as virtual) non-dllimported even if the attributes
are specified.
Regards,
Mumit