This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: [Darwin] Patch, take 2: enable linkonce support for Darwin
On Jan 30, 2004, at 4:01 PM, Richard Henderson wrote:
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.
OK, I'm happy to make that change.
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.
Do you have a better suggestion for the name? The problem is that
it really is a pretty esoteric issue: the issue is that if something is
an
implicit instantiation that only happens once, and where we don't
expect other implicit instantiations to happen in other translation
units,
and when there's a chance that the translation unit we're compiling
might find its way into a static archive, then on Darwin we need to make
it into an explicit instantiation instead of an implicit one. I called
it
TARGET_WEAK_NO_TOC because the issue is that, on Darwin,
coalesced symbols don't make it into the static archive's table of
contents.
Maybe it would be more honest if I didn't try to make up a target macro
for this, since it's just a very specific quirk, but just explicitly
special-
case Darwin. That's an ugly solution, but then, it's an ugly problem.
(For that matter, I wouldn't even mind too much just leaving this part
of the patch out, and dealing with the problem later. It's required for
correctness, but only in pretty esoteric cases. All of the tests in the
test suite work just as well without this.)
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.
The relevant code is in make_decl_one_only, which is in varasm.c. (It's
used by the C++ front end and also in one place in dwarf2out.c; I
suspect
it's indirectly used by the C++ front end there, too.)
Here's the case where we use COMMON even on SUPPORTS_ONE_ONLY
targets:
if (TREE_CODE (decl) == VAR_DECL
&& (DECL_INITIAL (decl) == 0 || DECL_INITIAL (decl) ==
error_mark_node))
DECL_COMMON (decl) = 1;
else if (SUPPORTS_ONE_ONLY)
...
I agree, it looks funny. Unless someone can explain to me why this is
a good
idea, I'd be happy to exchange the order of those clauses so that we
never
use COMMON if we've got ONE_ONLY available. The only reason I didn't
propose that in my original patch is that I wanted to be conservative,
and not
change the behavior of any non-Darwin 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.
I have no problem with that.
--Matt