On 11/05/15 11:31, Jakub Jelinek wrote: > On Mon, May 11, 2015 at 11:20:15AM +0100, Szabolcs Nagy wrote: >>> i think it might be enough to add __cpu_indicator_init_local >>> as an alias to __cpu_indicator_init in libgcc.a and then use >>> the *_local symbol from the ifunc resolver, that way no new >>> dependency is added to libgcc_s.so handling. >> >> i tried this approach and it seems to work: passes all >> multiversioning tests on x86_64. >> >> i think it's no worse than the symver approach. >> >> is it ok to change the current fix to this? > > No. Instead of piling hacks like this just fix it in musl. > libgcc certainly isn't the only library that uses @ symbol versions, > e.g. libstdc++ does as well, as well as many other shared libraries. >
can you explain how using a standard elf feature is a hack, but the current symver asm directive is not? fyi, musl loader loads libstdc++ just fine because it has no relocations for symbols which only has sym@version definition (libgcc_s.so.1 has because __cpu_indicator_init is a ctor). musl may end up supporting @version but that's an independent quest. (the one big pile of hacks here is multiversioning: each function with mv has its own ifunc resolver repeating the same logic, then the >1.5K cpuinfo.o is static linked into every single dso that uses mv and the separate __cpu_model structs all have to be initialized.. including the unused one in libgcc_s.so.1 because of the ctor.. adding more startup overhead. i'd gladly propose a patch to remove this feature if getting rid of piling hacks has priority.. the current design seems problematic to me for other archs that may need to call libc functions to do the dispatch anyway.)
