[PATCH 4/5 v1] LoongArch: Move ifunc info to rela.dyn from rela.plt.

liuzhensong liuzhensong@loongson.cn
Tue Jul 19 07:26:30 GMT 2022


在 2022/7/19 上午12:27, Xi Ruoyao 写道:
> On Mon, 2022-07-18 at 16:43 +0800, liuzhensong wrote:
>>    Delete R_LARCH_IRELATIVE from dynamic loader (glibc ld.so) when
>>    loading lazy function (rela.plt section).
>>
>>    In dynamic programes, move ifunc dynamic relocate info to section
>>    srelgot from srelplt.
> The main point of this change is allowing us to enable ifunc support for
> Glibc, right?
>
> But have you tested building Glibc using a ld with this series applied?
> It does not work well for me:
>
> FAIL: elf/ifuncmain1
> FAIL: elf/ifuncmain1pic
> FAIL: elf/ifuncmain1pie
> FAIL: elf/ifuncmain1staticpic
> FAIL: elf/ifuncmain1staticpie
> FAIL: elf/ifuncmain1vis
> FAIL: elf/ifuncmain1vispic
> FAIL: elf/ifuncmain1vispie
> FAIL: elf/ifuncmain3
> FAIL: elf/ifuncmain4
> FAIL: elf/ifuncmain5staticpic
> FAIL: elf/ifuncmain7
> FAIL: elf/ifuncmain7pic
> FAIL: elf/ifuncmain7pie
>
> Note that Binutils test suite is far from complete.  For example, the
> ifunc handling for LoongArch target in master branch (with or w/o this
> patch) can pass all ld tests, but it just blows up with a simple test
> case:
>
> $ cat c.s
> .global ifunc
> .type ifunc, @gnu_indirect_function
> .set ifunc, resolver
>
> resolver:
>    la.local $a0, impl
>    jr $ra
>
> impl:
>    li.w $a0, 42
>    jr $ra
>
> .data
> .global x
> .type x, @object
> x:
>    .dword ifunc
>
> $ cc c.s -shared
> collect2: fatal error: ld terminated with signal 11 [Segmentation fault], core dumped
> compilation terminated.
>
> So I think you'll at least need to build kernel/glibc/gcc using a ld
> with your patches to make sure it works correctly.

This is a bug, will be triggered:
1. a pointer point to a global ifunc,
2. compiling into a shared dynamic library.

We will fix and test this issue soon.



More information about the Binutils mailing list