This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]