On Mon, Mar 25, 2013 at 02:24:21PM -0700, Sriraman Tallam wrote: > Does this also mean that Paul's idea of doing: > > LD_CPU_FEATURES=sse,sse2 ./a.out # run as if only sse and sse2 are available > > is fraught with risk when used with IFUNC, particularly on x86_64? > > Shouldn't the IFUNC resolver go through the GOT even in this case. > This could work well for the MV testing problem I explained earlier, > but if this is not feasible with IFUNC in play I would like my > original proposal reconsidered.
I haven't been following the thread so can't comment, sorry. I jumped in on seeing Richard's suggestion re LD_PRELOAD, which is a bad idea given glibc's current support for STT_GNU_IFUNC. IFUNC as it stands is not a general purpose feature and interacts badly with other features of ELF shared libraries. Trivial testcases can easily be created that 1) won't work on any architecture. eg. shared library takes address of ifunc, ifunc resolver in main app, resolver uses variable in shared library. 2) only work on x86_64 and powerpc64. eg. shared library takes address of ifunc, ifunc resolver in main app which is PIC, resolver uses variable in main app. 3) won't work with LD_BIND_NOW=1 either of the above examples but shared library doesn't take address, just calls ifunc. The reason for these problems is that ld.so makes a single pass over dynamic relocations. In the simple case of LD_BIND_NOW=1 and an application that uses a single shared library, relocations for the library will be applied first, then relocations for the main app. So if the shared library has relocations against symbols that turn out to be ifunc, and the ifunc resolver lives in the main app, then the resolver will run *before* the main app has been relocated. The resolver had better not have code that requires relocation! Of course, the obvious fix of making ld.so do two passes over relocations, applying ifunc relocations on the second pass, is somewhat counterproductive. Mostly ifunc is used to gain a speedup when running on particular hardware. Two passes would have to slow down application startup.. Nonetheless, I believe that is the correct solution if we want to make ifunc generally useful. What we have at the moment requires quite a lot of care when using ifunc. Accidentally writing code that only works on x86_64 or powerpc64 is very easy, and might lead people to think you own shares in Intel or IBM. -- Alan Modra Australia Development Lab, IBM