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: Mumit Khan <khan at nanotech dot wisc dot edu>
- Subject: Re: Workaround for virtual function/dllimport bug, also patch guidance request
- From: Jason Merrill <jason at cygnus dot com>
- Date: 17 Dec 1999 18:11:04 -0800
- Cc: geoff schmidt <gschmidt at MIT dot EDU>, gcc at gcc dot gnu dot org
- References: <199912170645.AAA30147@mercury.xraylith.wisc.edu>
>>>>> 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