This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: Workaround for virtual function/dllimport bug, also patch guidance request


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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]