-fhidden-one-only and the EH runtime

[Matt Austern]

Aha!  Took me long enough, but I finally figured out why throwing an 
exception from one dylib and catching it in another actually worked in 
Apple's modified compiler, even though we'd made our typenames 
coalesced and private extern.  (In non-Apple terminology: weak and 
hidden.)

The answer: basically it was by accident.  Tracing through:
   1. The EH runtime compares two typeinfo objects with operator==.
   2. When operator== looks at two typeinfo objects, it first checks to 
see if they have the same address.  If they do, they're equal.  If they 
don't have the same address, and if __GXX_MERGED_TYPEINFO_NAMES is 
true, then they aren't equal.  If they don't have the same address and 
__GXX_MERGED_TYPEINFO_NAMES is not true, then it does string comparison 
on the names.
   3. This macro is set when libstdc++ is built.   It gets the same 
value as __GXX_WEAK__, which is set by the compiler.
   4. Finally, the compiler defines __GXX_WEAK__ to true iff it is built 
with SUPPORTS_ONE_ONLY.

So that's the accident: in Apple's compiler we've got the moral 
equivalent of ONE_ONLY semantics, but we didn't define 
SUPPORTS_ONE_ONLY.  That meant we didn't get 
__GXX_MERGED_TYPEINFO_NAMES, which meant the EH runtime allowed us to 
fall back on string comparison for typeinfo equality testing.

OK, now that I understand what's going on, let's get back to the 
original question: what do we have to do to support a compilation mode 
in which linkonce symbols are given hidden visibility?  The answer is 
that this is messier than I would have liked: you have to decide, when 
compiling libstdc++, whether or not you want to support such a mode.  
So the options I see are:
  1. Unconditionally enable that mode.  That is, define typeinfo's 
operator== so that it always falls back on string comparison when 
pointer comparison fails.
  2. Conditionally enable that mode.  (Perhaps controlled by a new 
configure switch?) If that mode isn't enabled, then the compiler will 
issue an error message for -fhidden-one-only.
  3. Forget about this mode, and remove it from my patch.  One-only 
symbols have global visibility, and that's that.

I've listed these options in order of my preference.  I can't actually 
think of a reason not to have typeinfo's operator== fall back on string 
comparison.  Sure it'll make it slower to see that a typeinfo 
comparison fails, but I don't think typeinfo comparison is ever used in 
a place where performance matters.  If anyone can show me a place where 
the performance of typeinfo's operator== is important, or where falling 
back on string comparison would cause a subtle correctness problem I 
didn't notice, then I'll change my mind.

			--Matt