Are ifuncs intended to be allowed to resolve to symbols in another DSO?

[Zack Weinberg <zackw at panix dot com>]

Suppose I have two major versions of the same shared library
(libfoo.so.1 and libfoo.so.2) and the only difference is that
libfoo.so.2 drops a whole bunch of compatibility aliases.  For
instance, libfoo.so.1 defines two names, `blurf` and `xblurf`, for the
same function, but libfoo.so.2 defines only the `blurf` name.

Any program that winds up loading both shared libraries (via
transitive dependencies) is going to have two copies of the actual
code for `blurf` in memory.  I could eliminate this duplication by
having libfoo.so.1 be a thin wrapper around libfoo.so.2, providing
only a definition for `xblurf` that calls `blurf`.  Good so far, but
now old applications are making two jumps through the PLT whenever
they call `xblurf`.  It occurred to me to wonder whether I could
eliminate the extra indirection (on the second and subsequent calls)
by making xblurf an ifunc:

extern int blurf(char *arg1, int arg2); // defined in libfoo.so.2
static int (*resolve_xblurf(void))(char *, int)
{
  return blurf;
}
int xblurf(char *, int) __attribute__((ifunc("resolve_xblurf")));

GCC 9.2 is perfectly happy to compile this and link it against a test
shared library containing an almost-trivial definition of 'blurf' (all
it does is call strlen and do some arithmetic), and a test program
that calls 'xblurf' will also compile, link, and even run to
completion correctly (using the dynamic loader from glibc 2.29).

However, reading https://sourceware.org/glibc/wiki/GNU_IFUNC gives me
the impression that this is probably *intended* to work but isn't
reliable in the current implementation, for reasons which I don't
follow.

So, my actual questions are: Is this intended to work?  If so, is this
actually reliable with current versions of the dynamic loader?  If so,
what is the oldest version of glibc where it's reliable?  Does it make
any difference if one or both of the libraries are linked with -z now?

zw