Cannot wrap IFUNC functions

[mplegendre]

Gotcha is not correctly handling wrapping of functions with IFUNC relocations. We need a different procedure for calcluating the wrappee function of these.

[mplegendre]

I had some thoughts on fixing this. Right now we look up the wrappee by name via searching every DSO for an exported symbol. That works fine for normal GOT-based function symbols, as it follows the same search pattern that the linker uses. But it's fragile for any symbols that need special handling, such as IFUNCs or any future relocation types we need to handle.

What if we instead just called the dynamic linker to do the binding? We would need to identify an existing call-site for that references that symbol (which we already do) and then call the dynamic linker resolve that callsite. We lift the linker's binding into our data structures, then overwrite the linker's decision with our wrappers.

[DavidPoliakoff]

I'm not sure what the implementation for this looks like, but I think the idea sounds fine, and possibly more generally useful. If we get a solution for this, I'd love to see whether it resolves our Intel OpenMP bugs.

[mwkrentel]

A quick note that I ran into this problem with some of the functions
from the math library. Most are FUNC, but a few are IFUNC including:

$ readelf -a /usr/lib64/libm-2.25.so | grep IFUNC
  312: 0000000000031390    56 IFUNC   WEAK   DEFAULT   14 cos@@GLIBC_2.2.5
  331: 00000000000313d0    56 IFUNC   WEAK   DEFAULT   14 sin@@GLIBC_2.2.5
  339: 0000000000036b90    56 IFUNC   GLOBAL DEFAULT   14 tan@@GLIBC_2.2.5
  ...

The problem here (besides not wrapping correctly) is that there is NO
indication of failure. gotcha_wrap returns SUCCESS, the wrapper
function does get called and gotcha_get_wrappee returns a non-NULL
pointer, but the function it returns acts like the identity function,
eg, sin(4.0) = 4.0.

So, you could wrap sin or cos, check all the return codes and you
would break the application without ever being told 'failure.'

[jrmadsen]

FWIW, I've experienced some stranger behavior with the math functions too. I was wrapping exp and on certain systems, it failed silently (probably for the same reasons) but on others, it was succeeding part of the time, e.g. I'd call the exp 2,000 times but my wrapper would get called maybe 60% of the time.

I've found you need to pay attention to the actual symbols that are linked into the exe. I spent far too long thinking there was something else was going wrong bc how can you screw up getting the symbol name of a C function. It turned out that I had accidentally publicly exported a -ffinite-math-only compiler flag elsewhere and as a result, the _exp symbol wasn't even indirectly linked into my application, nm <exe> | grep exp returned __exp_finite instead of _exp.

[hariharan-devarajan]

@mplegendre @jrmadsen Do we still need this feature?