Proposed change: weak symbol support for Darwin

[Matt Austern <austern at apple dot com>]

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.

Background: if you build the Darwin compiler, you'll notice that some 
C++ features are badly broken.  For example, put this in a header file:
  template <class T> struct X { static int n; };
  template <class T> int X<T>::n;

Then include that header file in two source files, say f1.cc and f2.cc. 
 In f1.cc define a function that sets X<int>::n to some arbitrary 
value.  In f2.cc call that function, and check to see whether X<int>::n 
has the value you set.  You'll find that it doesn't.

The basic problem is that the compiler thinks the Darwin linker has no 
way of supporting anything like linkonce or weak symbols.  This is a 
performance problem (duplicate copies aren't getting thrown away) and, 
as the above example shows, also a correctness problem.  There are 
similar correctness issues with static variables in inline functions, 
and so on.

How come nobody has complained about the fact that the Darwin compiler 
has a badly broken C++ implementation?  My guess is it's because most 
people don't use the Darwin compiler for C++; they use the Apple OS X 
compiler instead, which is based on the GNU Darwin compiler but which 
also includes Apple's local patches.  You see, the Darwin linker does 
provide this functionality.  It's not quite the same as GNU linkonce 
sections, but it's close enough; Apple calls it coalescing.

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 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!

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.

			--Matt