This is the mail archive of the
mailing list for the GCC project.
Re: [Darwin] Patch, take 2: enable linkonce support for Darwin
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.
> 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.