Name of indirect function evaluating to a hidden function?

[David Niklas]

On Tue, 10 Jan 2017 01:16:57 -0500
Carlos O'Donell <carlos@redhat.com> wrote: 
> On 01/09/2017 01:55 PM, listcrawler wrote:
> > Is "looking at dynamic relocation at the call site" parsing of the
> > GOT as suggested by yugr on stackoverflow? It did seem like a radical
> > solution, I'm looking for something more conventional.  
> 
> This is your only solution today.
> 
> > Are there other mechanisms I'm not aware of or is the simple answer
> > that lookup of the name of an indirect function just can not be
> > guaranteed?  
> 
> The problem is that there is no generic solution.
> 
> Consider the problem:
> 
> STT_GNU_IFUNC 'foo' has a resolver 'foo_resolve' which can return
> one of 3 functions 'foo1', 'foo2' or 'foo3'.
> 
> There is no information that connects 'foo1', 'foo2' or 'foo3' back
> to the STT_GNU_IFUNC 'foo'.
> 
> When you call dladdr the function has already been resolved to one
> of 'foo1', 'foo2' or 'foo3', and you've lost the information about
> the identity of the IFUNC symbol that they were related to.
> 
> Worse is that 'foo1', 'foo2' and 'foo3' might also be the returned
> functions of a STT_GNU_IFUNC 'bar', so there may be no single mapping
> that is correct (not that it matters to your example because both
> IFUNC 'foo' and IFUNC 'bar' would have to identically implement the
> same ABI/API).
> 
> In the cases where there is a 1:1 mapping we would be able to
> perhaps add metadata to the ELF file to allow dladdr to compute
> that 'foo1' came from IFUNC 'foo' and return information about
> IFUNC 'foo' e.g. the name.
> 
> Such resolved IFUNC symbol to IFUNC resolver mapping data does not
> exist today, and therefore dladdr will fail to return any data if the
> resolved to function is not global.
> 
> In your case the global symbol sin has an IFUNC resolver that returns
> a limb.so.6 local symbol __sin_avx, which is not listed in the dynamic
> symbol table and therefore fails to be returned from dladdr.
> 
> In the end we'd probably need an IFUNC symbol map hash to go from
> ifunc resolved function to original function, and that hash would need
> to be populated by developer information e.g. __attribute__
> ((ifunc_target("foo")))
> 
> Please feel free to file a bug about this.
> 
> Cheers,
> Carlos.

I was thinking about this and it seems to me that all you have to do
is compile the target and source programs with a particular
implementation of foo.
Then the code will not call a glibc function and you will not have a
problem.
Alternatively, you could try using musl, dietlibc, uclibc, or uclibc-ng
which might not have the special implementations of the said function.

Sincerely,
David