Re: [Darwin] Patch, take 2: enable linkonce support for Darwin

[Richard Henderson <rth at redhat dot com>]

On Fri, Jan 30, 2004 at 08:34:57AM -0800, Matt Austern wrote:
> The solution we came up with, which Apple has been using in our locally 
> modified compiler for two years, is to coalesce FDEs too.  We give 
> every FDE its own symbol (the name we choose is <foo>.eh, where <foo> 
> is the assembler name of the function the FDE corresponds to), so that 
> the FDEs too are coalesced.

Seems reasonable.

> To support all this exception machinery I put in a link from 
> dw_fde_struct back to the associated decl (we'll need that for other 
> targets, anyway, when and if we move to ELF group COMDAT), and I 
> introduced a new target macro, ASM_OUTPUT_UNWIND_LABEL, to give FDEs 
> their labels.  Everywhere but Darwin, that macro does nothing.

I'd definitely want this in the target structure, since it's 
quite clearly not a performance problem.

> I introduced a new target macro,  TARGET_WEAK_NO_TOC, 
> to control this behavior.

You'll have to get Jason to comment on this.  I certainly don't 
understand C++ linkage to know.

The name of the macro is pretty Darwin biased though.  When I 
look at it I think powerpc toc, as that's the only thing that
comes close to matching.

> Second quirk: Common is bad news.  Common symbols in Darwin can't have 
> hidden visibility and can't be exported from dylibs.   The second is 
> deliberate and the first is a bug, but both of them are things we have 
> to deal with.  So we really just shouldn't ever use common to implement 
> vague linkage, we should always use coalescing instead.  I introduced 
> another target macro, USE_COMMON_FOR_ONE_ONLY, so we can tell the 
> compiler about targets where common is a poor choice for representing 
> vague linkage.  (Again: this is not the same thing as -fno-common.  
> Common is fine in its place, just not for vague linkage.)

When do we do COMMON for C++?  Neither ELF-style nor GNU-style linkonce
should be using common symbols either.  Unless I'm missing something, I
wouldn't think we'd use COMMON with SUPPORTS_ONE_ONLY targets.

> Finally, one new user-visible feature: -fhidden-weak.  This flag makes 
> the compiler automatically give hidden visibility to symbols that have 
> vague linkage.

That does sound like it might prevent accidents, yes.

> Potentially questionable decisions.  First, I'm keying this off 
> DECL_ONE_ONLY, not DECL_WEAK.

That does sound better for your goal, but I'd rename the switch
lest it be confusing, -fhidden-linkonce or something.


r~