This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: [C++] GCC tree linkage types
On Thu, Nov 06, 2003 at 11:17:47PM -0600, Chris Lattner wrote:
> On 6 Nov 2003, Ian Lance Taylor wrote:
> > Chris Lattner <sabre@nondot.org> writes:
> > > In LLVM, we currently have the following linkage types:
> > >
> > > * internal linkage (ie, static)
> > > * linkonce (globals which merge when linking, but can be deleted from a
> > > translation unit if they are not used, basically like 'extern inline').
> >
> > I would normally say that linkonce means that all but one copy can be
> > deleted.
>
> Exactly, but what about the last copy? If it is unreferenced, can it be
> deleted? In LLVM, linkonce is used for things like vtables and extern
> inline functions. These things are guaranteed to be emitted in each
> translation unit that uses them, so it is ok for the optimizer to delete
> any copy that is not locally used. The front-ends already have a notion
> of this: if a logically "linkonce" global is not used, RTL code is not
> even generated for it.
>
> The distinction between linkonce and weak is much more important for
> link-time optimizations than it is for a compiler like GCC, though the
> compiler server and Apple IPO projects could definately use it.
I've gotten the feeling that LLVM has made an unfortunate choice of
names. You're using at least linkonce and weak in different ways than
GNU binutils and the existing ELF platforms use them. Weak undefined
means that the symbol can be missing; weak defined I can never
precisely remember, but within one linked object they can be shadowed.
This is going to cause no end of confusion - like DECL_COMDAT, which is
not always, quite COMDAT linkage.
> > The GNU linker supports more exotic linkage types like `indirect',
> > `warning', and `set'. But these are probably not of interest to the
> > compiler.
>
> True. What do these linkage types do? Are they documented somewhere? A
> google search didn't turn up anything obvious.
The GNU ld manual should describe them, but apparently doesn't... the
only one I know for sure is that a .gnu.warning.foo section causes a
warning if symbol foo is referenced in a link.
--
Daniel Jacobowitz
MontaVista Software Debian GNU/Linux Developer