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

[Mumit Khan]

Jason Merrill <jason@cygnus.com> writes:
>   
>  >   - import vtable as needed (we know about this, and can do it now)
>  >   - DO NOT import rtti info, but write it out. This is necessary to avoid
>  >     having to take the address of tinfo node, and currently it's impossibl
> e 
>  >     to do in gcc without writing out the vtable as well.
> 
> That's odd.  Why not import the RTTI info along with everything else?

Because of the usual `can't take the address of imported symbol' crap. 
The tinfo node for a derived class will contain addresses of (DLL 
imported) tinfo nodes of base classes, and that doesn't work. Something 
tells me that's why MSVC does it this way; of course this is just plain 
guesswork by looking at the assembler since there is absolutely no 
documentation on it. 

> 
>  > I don't know how to avoid writing vtables and still write out all the tinf
> o
>  > nodes/functions; however, we should be able to create a new macro, say
>  > CLASSTYPE_TINFO_NEEDS_WRITING, set that in import_export_class when
>  > import_export = -2 (or import_export > 0, the usual case), and somehow
>  > use that later on in finish_vtbls to just write out tinfo.
> 
> Or just use it in import_export_decl.
> 

But how to not emit vtables of imported classes, but at the same time, 
still emit the tinfo nodes? My experiments at implementation, or even 
just understanding how it really works, has failed so far.

The short term solution is to of course go back the old way of emitting
vtables for imported classes at the expense of much large, but working,
executables. The implies reverting your last patch of course.

Regards,
Mumit