[PATCH] RISC-V: Support GNU indirect functions.

[Nelson Chu]

Hi MaskRay,

Thank you very much for reporting this.

On Wed, Jul 15, 2020 at 12:44 PM Fangrui Song <i@maskray.me> wrote:
> For this test
> https://github.com/llvm/llvm-project/blob/master/lld/test/ELF/riscv-ifunc-nonpreemptible.s
>
> .text
> .globl func
> .type func, @gnu_indirect_function
> func:
>    ret
>
> .globl _start
> _start:
> .L:
>    auipc a0, %pcrel_hi(func)
>    addi a0, a0, %pcrel_lo(.L)
>
> Do you know why it reports this (spurious) diagnostic?
>
> % ld.lld -pie a.64.o -o a.64  # silent
> % ld-new -pie a.64.o -o a.64
> ....: warning: GNU indirect functions with DT_TEXTREL may result in a segfault at runtime; recompile with -fPIE
>
> There is also a spurious R_RISCV_NONE dynamic relocation, which should be fixed.
>
> % readelf -Wr a.64
>
> Relocation section '.rela.dyn' at offset 0x210 contains 1 entry:
>      Offset             Info             Type               Symbol's Value  Symbol's Name + Addend
> 0000000000000000  0000000000000000 R_RISCV_NONE                              0
>
> Relocation section '.rela.plt' at offset 0x228 contains 1 entry:
>      Offset             Info             Type               Symbol's Value  Symbol's Name + Addend
> 0000000000002010  000000000000003a R_RISCV_IRELATIVE                         270

I need to see the riscv_elf_check_relocs again and think of the
details.  I believe all R_RISCV_NONE and redundant dynamic relocation
problems can be resolved by rewriting the riscv_elf_check_relocs,
according to the TLS issues reported by you before.

> This test checks a non-GOT-non-PLT relocation to a STT_GNU_IFUNC.
> Such relocations can be used to take the address of the indirect function.
> To make sure pointer equality holds (i.e. taking the address from another module will get the same address),
> LLD will create a PLT (called "canonical PLT" among a few linker people),
> change func's type to STT_FUNC, and redirect all references to the PLT.

Oh... This should be fixed.  Looks like the
_bfd_x86_elf_link_fixup_ifunc_symbol that I didn't notice before...

I will come back to deal with these problems, including what you have
suggested in the previous mail, ASAP.  Maybe a few days later.


Thank you very much
Nelson