Re: Proposed change: weak symbol support for Darwin

[Matt Austern <austern at apple dot com>]

On Monday, October 13, 2003, at 05:07  PM, Zack Weinberg wrote:

> Matt Austern <austern@apple.com> writes:
>
> > I don't yet have a patch for this change; I'm sending out a message
> > because I'd like very much to get it into 3.4, and I'll have to bend
> > the deadline slightly to do it.  I wanted to see if people thought
> > that was OK before doing much more of the work.
> ...
>
> > There's no good reason for coalescing to be implemented as a bunch of
> > local Apple patches.  It should all be in the Darwin back end, and all
> > the compiler should care about (for the most part) is that Darwin has
> > a way of making symbols one-only.  I'd like to fix Darwin's C++
> > implementation by teaching the Darwin back end how to do coalescing
> > properly.
> >
> > 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.
>
> 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 not that hard.  Currently we've got four cases for polymorphic 
classes:
 (1) It's an ordinary (nontemplate) class, with at least one virtual
     function that isn't declared inline in the class definition.  In
     that case we emit the vtable in the translation unit where the 
first
     noninline virtual function is defined.  By the ODR this means we 
will
     emit the virtual function in only one translation unit, except 
for...
 (2) Same as above, except that the first noninline virtual function 
later
     turns out to have an inline definition.  In that case we must emit 
the
     vtable in every translation unit where the definition appears.
 (3) Every virtual function is declared inline in the class definition. 
 In
     that case we emit the vtable in every translation unit where the
     definition is needed.
 (4) It's a class template.  In that case we emit the vtable in every
     translation unit where the class template is instantiated.

I'm describing what the compiler currently does, by the way, not my 
proposal.
And currently we make the vtable weak for all four cases.

My proposal is to change the compiler, for Darwin only, so that it only
makes the vtables weak for cases 2-4.  I don't see any good reason to 
make
that change on any other platforms, but I'd be happy to do it if anyone 
can
think of a reason why it would be an improvement.

We've already made this change internally at Apple.

			--Matt