This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: [C++] GCC tree linkage types
- From: Ian Lance Taylor <ian at wasabisystems dot com>
- To: Chris Lattner <sabre at nondot dot org>
- Cc: Matt Austern <austern at apple dot com>, <gcc at gcc dot gnu dot org>, Gabriel Dos Reis <gdr at integrable-solutions dot net>, Richard Henderson <rth at redhat dot com>
- Date: 07 Nov 2003 10:25:26 -0500
- Subject: Re: [C++] GCC tree linkage types
- References: <Pine.LNX.4.44.0311070909560.18330-100000@nondot.org>
Chris Lattner <sabre@nondot.org> writes:
> I understand that exactly. In LLVM, in C (not C++), a variable
> initialized with zero becomes a strong symbol with external linkage. A
> variable without an initializer gets weak linkage. I still do not see the
> difference in semantics. You are confusing what linkers _happen to
> currently implement_ with the need of the source languages. I'm more
> interested in what it takes to implement language requirements
> efficiently.
I honestly don't think I am confusing anything. We are talking about
several different kinds of symbols with different link-time semantics.
Common symbols and weak symbols have different semantics; I just
described common symbol semantics in my last message, and they are
clearly not the same as weak symbol semantics. It's not a matter of
what linkers happen to currently implement; these different types of
symbols have well-defined semantics, and all linkers can and do
implement them the same way (modulo a long-standing and relatively
unimportant disagreement about the handling of weak symbols in ELF).
You may be saying that the different link-time semantics don't matter;
in the real world, I don't think that is correct.
>From an idealized language perspective, there is really only one type
of defined symbol--an ordinary strong definition. For efficient
implementation of C++, we add provisional symbols (which you are
calling linkonce), and linkonce symbols (which you are calling weak).
For correct implementation of FORTRAN, we must also add common
symbols; common symbols are also used in traditional C environments.
(Again, common symbols are not the same as weak symbols; if gcc
emitted common symbols the same way that it emits weak symbols, it
would produce incorrect results for FORTRAN.)
Once we leave the idealized language perspective, we must consider the
needs of library maintainers. In gcc these have led to language
extensions in the form of function and variable attributes. Some
attributes which have link-time semantics are section, constructor,
destructor, weak, alias, and shared. The first three and the last one
are implemented using special section semantics; weak and alias are
implemented (at least in ELF) using two forms of the weak symbol type
(which is not quite the same as what you are calling weak). You can't
just lump all these things together, or you will get the wrong result.
Ian