[PATCH v8 3/6] riscv: Add __riscv_hwprobe pointer to ifunc calls

Fangrui Song maskray@google.com
Tue Oct 17 04:46:41 GMT 2023


On 2023-09-29, Florian Weimer wrote:
>* Jessica Clarke:
>
>> Being able to write portable IFUNC resolvers across Linux, BSDs and
>> other similar OSes is valuable, and this would preclude that. In FreeBSD
>> there are no issues with calling functions from IFUNC resolvers; we just
>> process all non-IRELATIVE relocations before IRELATIVE ones.
>
>Even across multiple objects?  In glibc, we rely on relocation order by
>the link editor to put IRELATIVE last, so we don't have that particular
>problem for IRELATIVE, but we have it for regular symbol-based
>relocations that happen to refer to IFUNC symbols because the relocation
>order my not reflect the symbol binding order.
>
>Thanks,
>Florian

As a resolution to
https://sourceware.org/bugzilla/show_bug.cgi?id=13302
("IRELATIVE relocation should come last"), GNU ld places IRELATIVE in
.rela.plt (strange, as IRELATIVE is not lazy).

I think relyong on this is too brittle, as IRELATIVE may be in .rela.dyn .  I have just filed
https://sourceware.org/bugzilla/show_bug.cgi?id=30976
("rtld: resolve ifunc relocations after JUMP_SLOT/GLOB_DAT/etc")
based on my examples at https://maskray.me/blog/2021-01-18-gnu-indirect-function#relocation-resolving-order


FreeBSD rtld uses multiple phases and in my analysis

> The approach turns out to be very robust. Many segfault examples on
> glibc work on FreeBSD.

glibc rtld probably does not need to do so much. Just refactoring the loop in elf/dynamic-link.h
so that IRELATIVE, regardless of .rela.dyn or .rela.plt, will work for
my examples.  Then the outcome will look good enough to me.

   for (int ranges_index = 0; ranges_index < 2; ++ranges_index)


More information about the Libc-alpha mailing list