[Bug lto/47247] Linker plugin specification makes it difficult to handle COMDATs

["hubicka at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47247

--- Comment #22 from Jan Hubicka <hubicka at gcc dot gnu.org> 2011-08-27 17:35:27 UTC ---
Carry,
is there any chance to move ahead on this problem?  I see you posted the
PREVAILING_DEF_IRONLY_EXP but it was never committed.

Concerning Rafael's comment:

 Why is PREVAILING_DEF_IRONLY_EXP needed? I think it can be solved with 
just PREVAILING_DEF if we say that the compiler can drop references to 
them if it knows they are provided in any DSO. The only case I can see 
where this would almost be a problem is something like

This is not possible with current formulation of plugin API. It explicitely
says "Any symbol marked PREVAILING_DEF must be defined in one object file added
to the link after WPA is done, or an undefined symbol error will result"

We could also go that route I guess, but
 1) We will have to bump API version or something to indicate whether compiler
is allowed to drop the symbols or not.  With current binutils implementation
bad things happens when compiler decided to drop the symbol it is not supposed
to (my original implementation did so and it resulted in problems, especially
in large dynamic linker tables)
 2) the LTO produced COMDAT function will likely be better, so we will lose bit
of code quality
 3) There are cases where function is output COMDAT but it is keyed (i.e. with
the repo files). In this case we will not be able to drop the symbol when it
becomes unnecessary at LTO time because we will not know whether the symbol is
used by non-LTO code or not.

All those reasons are rather side cases and thus weak, but because we are
effectively changing API anyway and because PREVAILING_DEF_IRONLY_EXP makes
compiler a bit more informed in well defined way, I would go for it.

Honza