[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