Re: [google][4.7]Using CPU mocks to test code coverage of multiversioned functions

[Alan Modra <amodra at gmail dot com>]

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