[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