> On Wed, 21 May 2014, Jan Hubicka wrote: > > > I tought glibc uses handcoded local aliases for all its exported symbols > > except > > for those where interposition is allowed. > > It does that for exported symbols. But there are lots of non-exported __* > functions used internally - and while some are declared hidden (or use the > facility for hidden aliases), I suspect lots are not, so it's only the > linker scripts that default-hide symbols that result in them not being > interposable (and I'm guessing this effect of a linker script is too late > for LTO to optimize based on that information).
This is actually good question, do you think you can check if such symbol get LDPR_PREVAILING_DEF_IRONLY instead of LDPR_PREVAILING_DEF_IRONLY_EXP? It would make sense for linker to do so and GCC will then privatize the symbols (turn them to static). If GNU LD or gold will declare them LDPR_PREVAILING_DEF_IRONLY_EXP, we probably could fill in enhancement request. The problem would be symbols that are used by non-LTO objects but still turned hidden by the script - those would get LDPR_PREVAILING_DEF and since we do not have LDPR_PREVAILING_DEF_EXP, we don't have the information that they are hidden... Introducing LDPR_PREVAILING_DEF_EXP is possible with another revision of plugin API, but I am not sure it is worth the effort. But yes, having way to tell this to non-LTO compiler would be nice. I wonder if visibility attribute is right mechanism or the proposed -fsemantic-interposition=<list> Honza > > -- > Joseph S. Myers > jos...@codesourcery.com
