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


>>>>> Mumit Khan <khan@nanotech.wisc.edu> writes:

 > Jason Merrill <jason@cygnus.com> writes:

 >> 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. 

Does that apply to all non-functions?  Why?  How do we import vtables, then?

 > 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.

import_export_decl decides what linkage a function has.  finish_file then
decides whether to compile it (based on TREE_USED, for a tinfo fn) and
whether to write it out (based on DECL_NEEDED).

 > 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.

I'd prefer to spend the time to get it right.

Jason


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