This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Proposed change: weak symbol support for Darwin
- From: Matt Austern <austern at apple dot com>
- To: GCC list <gcc at gcc dot gnu dot org>
- Date: Mon, 13 Oct 2003 15:32:01 -0700
- Subject: Proposed change: weak symbol support for Darwin
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