PATCH] PR target/65612: Multiversioning doesn't work with DSO nor PIE

[Szabolcs Nagy]

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.)