This is the mail archive of the libc-alpha@sourceware.org mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [PATCH] S390: Refactor ifunc handling


Hi all,

after all the comments, we've also re-discussed the approach internally.
We still see more advantages (apart from performance-perspective) than disadvantages and thus plan to commit the patches if there are no strong objections.

I've summarized some points:
-Reducing code size as not used ifunc variants are omitted. E.g. when building with march >= zEC12 we have only one variant for memset, memcmp, memcpy instead of three for each. When building with march >= z13 we have only the vector variants for the string functions.

-Ifunc symbols are avoided at all (if we have only one remaining ifunc variant). In the most tools like binutils, gdb and co, ifunc symbols are implemented as separate more complex code paths. Thus we think it is better to have less ifuncs. E.g. setting a breakpoint on an ifunc'ed symbol is more complicated than for an usual symbol.

-Automatically using the best available ifunc variant as glibc internal symbol (depending on the used gcc-options) without adding the plut-stub-overhead. The same applies to --disable-multiarch and ld.so.

-Introducing ifunc'ed glibc internal symbol is not possible on s390-32 as a non plt-relocation is generated by gcc but an implicit plt-stub is used. The plt-stub needs the GOT-pointer in r12 which was not loaded by gcc.

-Calling a non-ifunc'ed glibc internal symbols is just a brasl to this symbol. There are no special hacks. What shall go wrong? Whereas calling an ifunc'ed glibc internal symbol involves the additional special plt-stub.

-As the code is shared between s390-32 and s390-64 we do not want to introduce ifunc'ed glibc internal symbols for e.g. s390-64 and non-ifunc'ed ones for s390-32.

-Testing glibc needs to be done for all march-levels - with or without these patches. Thus we don't see the more testing effort.

-Testing the implementation of all different ifunc variants of a specific function is still possible with ifunc-impl-list mechanism if march-level is set to the oldest march-level.

Bye
Stefan


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]