This is the mail archive of the
mailing list for the GCC project.
Re: LTO plugin and comdat symbols
- From: Ian Lance Taylor <iant at google dot com>
- To: Jan Hubicka <hubicka at ucw dot cz>
- Cc: ccoutant at google dot com, tglek at mozilla dot com, rguenther at suse dot de, gcc-patches at gcc dot gnu dot org, dnovillo at google dot com
- Date: Wed, 06 Oct 2010 07:14:22 -0700
- Subject: Re: LTO plugin and comdat symbols
- References: <20101006124620.GA31464@kam.mff.cuni.cz>
Jan Hubicka <firstname.lastname@example.org> writes:
> I think in this case it would make sense to change gold's behaviour by marking
> externally visible symbol that are not explicitely used by other object files
> at PREVAILING_IRONLY instead of PREVAILING_DEF. I always assumed gold behaving
> thisw way and it would give GCC freedom to take the symbol again.
> GCC by itself has all the info it needs to know if the symbol is exported from DSO
> so it will not remove non-COMDATs. Would that be possible?
This does not make sense when using -shared. When using -shared, any
symbol with default visibility is externally visible and should appear
in the dynamic symbol table. That is how shared libraries work. It
would not be appropriate for gold to change that.
It is true that inlining can change the set of visible symbols. It
would be more robust for Mozilla to use version scripts at link time to
list which symbols should be exposed from each shared library.
It is also true that if there is no remaining definition of or reference
to the symbol that there is no need for the symbol to go into the
dynamic symbol table. It should, I hope, be possible to change that in
gold and/or the LTO plugin, and I think that would solve your problem.