Re: Name of indirect function evaluating to a hidden function?

[Carlos O'Donell <carlos at redhat dot com>]

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.