It was already reported on binutils [1] and on lld [2]. The current behavior for ld on arm is to put IRELATIVE on .rel.dyn but I am not sure why exactly (Peter hinted it is a "legacy of ARM having a single .got section", and I am not sure if ld still have this limitation yet).

So 'fixing' it won't gain us anything with current supported static linkers.  It might improve support on arm ifunc itself (for instance to be able to call R_ARM_JUMP_SLOT functions, since ifunc will be reordered last), but what ifunc is able to do is not properly documented and has a lot of pitafalls that calling external functions (from current TU) is always 'tricky'.

And even if we change it, a static-linker that only emits IRELATIVE on .rel.plt will need to prevent to run on older glibc (as we did for DT_RELR with a extra symbol).

So the question is whether you need this changed.  Do you need it for your mold linker?

[1] https://sourceware.org/bugzilla/show_bug.cgi?id=19891
[2] https://reviews.llvm.org/D26029
[3] https://sourceware.org/glibc/wiki/GNU_IFUNC

I added support for ifunc this way to mold and found that although it worked perfectly fine on x86-64 and other targets, it didn't on arm32 and ppc64. I abandoned that change, so I no longer have a strong opinion on this. That said, I still think that it would have been better if glibc worked the same way across all targets.

Since IFUNC support was added in a most ad-hoc way for each architecture, there is no unified code to generate it with binutils or to handle on glibc.

We can implement your suggestion and add support for .rel.plt IRELATIVE handling on arm and PPC, however it will only work for linkes that implement it and there will be issues on how to avoid such binaries to run on older glibcs. 

The glibc now avoids random failures if there is missing support and instead dumps an error on why it has failed.

So essentially this change for ARM and PPC will be similar to what we have done for DT_RELR: we will need the static linker to advertise that IFUNC is now placed on .rel.plt instead of .rel.dyn so glibc can avoid starting the binary if it has no support.  For DT_RELR both binutils and lld now add an extra version tag GLIBC_ABI_DT_RELR on .gnu.version_r to indicate it.  For instance on a glibc binary built with DT_RELR support:

Version needs section '.gnu.version_r' contains 1 entry:
 Addr: 0x0000000000000998  Offset: 0x000998  Link: 7 (.dynstr)
  000000: Version: 1  File: libc.so.6  Cnt: 4
  0x0010:   Name: GLIBC_ABI_DT_RELR  Flags: none  Version: 5
  0x0020:   Name: GLIBC_2.4  Flags: none  Version: 4
  0x0030:   Name: GLIBC_2.34  Flags: none  Version: 3
  0x0040:   Name: GLIBC_2.2.5  Flags: none  Version: 2

Older glibcs will fails with a missing GLIBC_ABI_DT_RELR version trying to bind the version.

So if we want to add support for IRELATE on .rel.plt for ARM and PPC we need a similar change, where static linkers add a GLIBC_ABI_IFUNC_REL_PLT version tag.

(In reply to Adhemerval Zanella from comment #3)
> 
> So if we want to add support for IRELATE on .rel.plt for ARM and PPC we need
> a similar change, where static linkers add a GLIBC_ABI_IFUNC_REL_PLT version
> tag.

In fact, we already have the 'unexpected PLT reloc type' error so there is no need to add a new symbol version (although the error is not clear). 

So I do not really opposes it, but again the actual gain is quite minimal and a linker that only emits IRELATIVE on .rel.plt will create binaries that only work on very recent glibc.

I thought that the intention of glibc is to support that usage on all targets and somehow a few targets didn't support it. So, if it needs more work than just implementing it so that it will be usable someday in the future, I don't think it's worth to pursue. It's not that important anyway. I'll close this issue as "won't fix".