https://sourceware.org/bugzilla/show_bug.cgi?id=25205
--- Comment #7 from Jim Wilson <wilson at gcc dot gnu.org> --- I can reproduce with your object files. I had to add a -B option to find crtbegin.o and libgcc.a. Maybe something wrong with clang on my system. Anyways, what I see is that in _bfd_riscv_relax_section, if there is a PLT then we use it unconditionally. However, in riscv_elf_relocate_section, a PLT is only used if bfd_link_pic, i.e. the output is a shared library or PIE. So we are relaxing using a different symbol address than what we are linking for which causes the trouble. Since this is a linker relaxation problem, it must be _bfd_riscv_relax_section that is wrong. Adding a check for bfd_link_pic solves the linker errors. But there is still a potential problem that we aren't handling undef weak functions in riscv_elf_relocate_section if there is a PLT, which could be a problem if a program is linked to run at a high address out of range of 0. This is common for embedded but probably not for linux, but I think we should still fix it. So I need to add a !bfd_link_pic check there. Now I see stuff like d3d54: 00000097 auipc ra,0x0 d3d58: 000000e7 jalr zero # 0 <_PROCEDURE_LINKAGE_TABLE_-0xa0050> d3d5c: e10d bnez a0,d3d7e <_ZN4llvm24initializeDumpModulePassERNS_12PassRegistryE+0x86> in the final opt binary which is what I want for a call to an undefined weak function. Curiously, I can't run the opt binary even though ldd says it is OK. I'm not sure what is wrong there but don't think it matters. -- You are receiving this mail because: You are on the CC list for the bug.
