On Mon, Jun 16, 2014 at 11:44 PM, Jan Hubicka <hubi...@ucw.cz> wrote:
>> The linker is not seeing the local definition of >> ._ZN14__gnu_parallel9_SettingsC1Ev. libstdc++ is built with >> Linux-like semantics, so it allows symbols to be overridden. AIX calls >> everything through the PLT. But the real definition of the function is > > Even static functions? > >> not being seen. >> >> I'm not exactly sure why inlining changing this and what these extra >> levels of indirections are trying to accomplish. The visibility of the > > To avoid using PLT and GOT when the unit refers to the symbol and we know > that interposition does not matter. I am not certain if the linker is creating the PLT stub code because it wants to allow interpolation or because it cannot see a definition of the function and wants to allow for some other shared library to provide the definition at runtime. > Why branch to a non-global (static) symbol > b ._ZN14__gnu_parallel9_SettingsC1Ev.localalias.0 > leads to PLT stub here and why branching to such symbols seems to work > otherwise? Branching to non-global (static) symbol, even an alias, is working here. The weak function seems to be the problem. > The failing branch is >> b ._ZN14__gnu_parallel9_SettingsC1Ev.localalias.0 > so the call to static construction seems to have happened correctly but we can > not get right the call from the constructor to static function (that is an > alias > of a global symbol) The linker appears to not want to resolve the weak function. If I change ._ZN14__gnu_parallel9_SettingsC1Ev to lglobl, it works. If I change the static constructor to call the weak function directly, avoiding the alias, it shows the same failure mode. I don't know what code generation looked like before. Was GCC generating calls to weak functions within the same file? Thanks, David
