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

Nelson Chu nelson.chu@sifive.com
Wed Jul 8 09:12:40 GMT 2020


Hi MaskRay,


On Wed, Jul 8, 2020 at 3:22 PM Fangrui Song <i@maskray.me> wrote:
>
> I think I know ifunc and its implementation in LLD quite well
> (https://reviews.llvm.org/D74022 ). However, I know little about GNU ld
> and its terminology, so please bear with me.

I would like to thank you for your suggestions and the great ideas.
So please feel free to join the discussion.


> The test naming is really terrible. It is difficult to understand the
> purpose of individual files. Can they have more descriptive names?

Agreed... I just keep the original naming when porting them from
ld/testsuite/ld-ifunc/.  I do plan to improve these, the descriptive
names should help, or we probably can add some comments to describe
them in the ld-riscv-elf.exp.  I will add some comments first in the
ld-riscv-elf.exp, and then will try to give them the more descriptive
names.  However, thanks for the suggestion.


> ifunc-1.s and ifunc-3.s are identical except a visibility setting.
> Can the tests be somehow combined? For example,
> echo '.hidden foo' > a.s and then concatenate two assembly files

This may be one of the ways to combine the assembly files.  Another
way is used in the ifunc-10.s, it should also work.  We can define the
symbols by "-defsym xxx=1" to assembler, and then use ".ifdef xxx" to
decide which code patterns are prefered to be generated.  I remember
not only ifunc-1.s and ifunc-3.s can be combined, so we probably can
reduce the entire number of the ifunc testcases.


> >+      if (h != NULL)
> >+      {
> >+        switch (r_type)
> >+          {
> >+          case R_RISCV_32:
> >+          case R_RISCV_64:
> >+          case R_RISCV_CALL:
> >+          case R_RISCV_CALL_PLT:
> >+          case R_RISCV_HI20:
> >+          case R_RISCV_GOT_HI20:
> >+          case R_RISCV_PCREL_HI20:
>
> The list has appears more than once with variance, I think a generic
> relocation kind may help.

I assume you mean something like "_bfd_elf_x86_valid_reloc_p" or some
macros defined in the bfd/elfxx-x86.h.  If so, yeah that's a good
idea.  I think generic relocation kinds are helpful.


> (Off-topic
> I think -z separate-code being default on linux x86 since binutils 2.31
> is not the best choice. GNU ld should have --rosegment like gold and LLD.
> -z separate-code should be responsible for overlapping p_offset
>
> https://reviews.llvm.org/D64903)

Thanks for the information.  I will figure this out.


Thank you very much, and other suggestions are also welcome.
Nelson


More information about the Binutils mailing list