This is the mail archive of the
mailing list for the GCC project.
Re: Proposed change: weak symbol support for Darwin
- From: Matt Austern <austern at apple dot com>
- To: Zack Weinberg <zack at codesourcery dot com>
- Cc: GCC list <gcc at gcc dot gnu dot org>
- Date: Mon, 13 Oct 2003 18:28:21 -0700
- Subject: Re: Proposed change: weak symbol support for Darwin
On Monday, October 13, 2003, at 05:07 PM, Zack Weinberg wrote:
Matt Austern <firstname.lastname@example.org> 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
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
It's not that hard. Currently we've got four cases for polymorphic
(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
noninline virtual function is defined. By the ODR this means we
emit the virtual function in only one translation unit, except
(2) Same as above, except that the first noninline virtual function
turns out to have an inline definition. In that case we must emit
vtable in every translation unit where the definition appears.
(3) Every virtual function is declared inline in the class definition.
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
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
that change on any other platforms, but I'd be happy to do it if anyone
think of a reason why it would be an improvement.
We've already made this change internally at Apple.