Re: Proposed change: weak symbol support for Darwin

["Zack Weinberg" <zack at codesourcery dot com>]

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.

You say exporting coalesced symbols is too intricate for most users,
but is it too intricate for the compiler to use?  We can take care to
do the right thing, I'd think.

> I might also have to steal one bit in decl nodes to cope with the
> Darwin linker's notion of "private extern" symbols, i.e. symbols
> that are public within a dynamic library but that aren't exported
> beyond the scope of the library boundary.  Of course, if anyone can
> tell me about a flag that's already there and that has that meaning,
> so much the better!

This sounds just about equivalent to the ELF concept of "visibility
hidden" -- look for existing support for that.  There are several
visibility __attribute__s, and you are encouraged to support as many
of them as possible.

> Does this sound reasonable to people?  It's slightly beyond the scope
> of what most of us imagine for stage 3.  On the other hand, it will be
> almost entirely localized to Darwin-specific files and it really is a
> Darwin bug fix.

My feeling is that this would be appropriate for stage 3, especially
early stage 3, if the changes to generic code are carefully kept
small.  Mark may disagree.

zw