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]
Other format: [Raw text]

Re: Proposed change: weak symbol support for Darwin


Matt Austern <austern@apple.com> writes:
> > This will require a tiny bit of work in the generic front end.  By
> > default, Apple doesn't export coalesced symbols from dynamic
> > libraries: the combination of coalescing, dynamic linking, and various
> > esoteric linker features, is intricate enough that we don't think it's
> > appropriate for most users.  This means we have to be slightly careful
> > about marking a symbol coalesced.  In particular we have to be careful
> > with vtables: we can't mark all vtables coalesced, only the ones that
> > really will be emitted in multiple translation units. 

On Mon, Oct 13, 2003 at 05:07:50PM -0700, Zack Weinberg wrote:
> I am not sure what this entails, and it's not clear to me whether the
> compiler can tell when a vtable is going to be emitted in multiple
> translation units.  This sounds like the most problematic part of your
> proposal.

It's the old cfront heuristic: the vtable is emitted only by the
compilation unit that defines the first non-inline virtual member function
of the class.  By the one-definition rule, there can be only one such
unit, so the vtable can be emitted once as a "strong" symbol.  This trick
is better than generating it in every unit and then trying to wipe all but
one out.

However, if all of a class's virtual members are defined inline, weak
symbols, or internal linkage (if we have no weak symbol support) must be
used for vtables.

So, it seems that you only want to use coalescing for those vtables that
need to be emitted as weak symbols.


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