]> git.ipfire.org Git - thirdparty/glibc.git/commit
LoongArch: Call elf_ifunc_invoke for R_LARCH_IRELATIVE in elf_machine_rela
authorXi Ruoyao <xry111@xry111.site>
Fri, 7 Nov 2025 15:49:22 +0000 (23:49 +0800)
committercaiyinyu <caiyinyu@loongson.cn>
Wed, 12 Nov 2025 01:12:48 +0000 (09:12 +0800)
commit2f5e68dea9deeb1b0a6bc9ffc84d5e45af445e36
treeb3bd71824595415b13af6724ee1b78c0d267454c
parentf851a7434696b70ce7c266ade1de2469619e6f52
LoongArch: Call elf_ifunc_invoke for R_LARCH_IRELATIVE in elf_machine_rela

When R_LARCH_IRELATIVE is resolved by apply_irel, the ifunc resolver is
called via elf_ifunc_invoke so it can read HWCAP from the __ifunc_arg_t
argument.  But when R_LARCH_IRELATIVE is resolved by elf_machine_rela (it
will happen if we dlopen() a shared object containing R_LARCH_IRELATIVE),
the ifunc resolver is invoked directly with no or different argument.
This causes a segfault if the resolver uses the __ifunc_arg_t.

Despite the LoongArch psABI does not specify this argument, IMO it's
more convenient to have this argument IMO and per hyrum's rule there may
be objects in wild which already relies on this argument (they just
didn't blow up because they are not dlopen()ed yet).  So make the
behavior handling R_LARCH_IRELATIVE of elf_machine_rela same as
apply_irel.

This fixes BZ #33610.

Signed-off-by: Xi Ruoyao <xry111@xry111.site>
sysdeps/loongarch/dl-machine.h