binutils-gdb/ld/testsuite/ld-riscv-elf/pcrel-lo-addend-3b.d

#source: pcrel-lo-addend-3b.s
#as: -march=rv64i -mabi=lp64 -mno-relax
#ld: -m[riscv_choose_lp64_emul] -Tpcrel-lo-addend-3.ld
#error: .*dangerous relocation: The addend isn't allowed for R_RISCV_GOT_HI20
RISC-V: Clarify the addends of pc-relative access. The original discussion was here, https://github.com/riscv/riscv-elf-psabi-doc/issues/184 After discussing with Kito Cheng, I think the addends of %pcrel_hi and %pcrel_lo are both allowed in GNU toolchain. However, both of the them mean the offset of symbols, rather than the pc address. But the addends of %got_pcrel_hi and it's %pcrel_lo do not look reasonable. I believe gcc won't generate the got patterns with addends, so linker should report dangerous relocation errors, in case the assembly code use them. Another issue was here, https://sourceware.org/pipermail/binutils/2021-June/116983.html At the beginnig, I suppose %pcrel_hi and %pcrel_lo are valid only when they are in the same input section. But Jim Wilson points out that gcc may generate %hi and %lo in the different input sections, when -freorder-blocks-and-partition option is used. So that a memory references for a loop may have the %hi outside the loop, but the %lo remain in the loop. However, it is hard to create the testcases, to see if %pcrel_hi and %pcrel_lo have the same behavior. Unfortunately, I notice that the current pcrel resolver cannot work for the above case. For now we build a hash table for pcrel at the start of riscv_elf_relocate_section, and then free the hash at the end. But riscv_elf_relocate_section only handles an input section at a time, so that means we can only resolve the %pcrel_hi and %pcrel_lo which are in the same input section. Otherwise, like the above case, we will report "%pcrel_lo missing matching %pcrel_hi" for them. I have no plan to improve this in the short-term, so maybe we can wait until someone meets the problem before we deal with it. bfd/ * elfnn-riscv.c (riscv_pcrel_hi_reloc): Added field to store the original relocation type, in case the type is converted to R_RISCV_HI20. (riscv_pcrel_lo_reloc): Removed unused name field. (riscv_pcrel_relocs): Added comments. (riscv_zero_pcrel_hi_reloc): Removed unused input_bfd. (riscv_record_pcrel_hi_reloc): Updated. (riscv_record_pcrel_lo_reloc): Likewise. (riscv_resolve_pcrel_lo_relocs): Likewise. Check the original type of auipc, to make sure the %pcrel_lo without any addends. Otherwise, report dangerous relocation error. (riscv_elf_relocate_section): Updated above functions are changed. For R_RISCV_GOT_HI20, report dangerous relocation error when addend isn't zero. ld/ * testsuite/ld-riscv-elf/ld-riscv-elf.exp: Updated. * testsuite/ld-riscv-elf/pcrel-lo-addend-3a.d: New testcase. * testsuite/ld-riscv-elf/pcrel-lo-addend-3a.s: Likewise. * testsuite/ld-riscv-elf/pcrel-lo-addend-3b.d: New testcase. Should report error since the %pcrel_lo with addend refers to %got_pcrel_hi. * testsuite/ld-riscv-elf/pcrel-lo-addend-3b.s: Likewise. * testsuite/ld-riscv-elf/pcrel-lo-addend-3c.d: New testcase. Should report error since the %got_pcrel_hi with addend. * testsuite/ld-riscv-elf/pcrel-lo-addend-3c.s: Likewise. * testsuite/ld-riscv-elf/pcrel-lo-addend-3.ld: Likewise. 2021-06-22 12:02:52 +08:00			`#source: pcrel-lo-addend-3b.s`
			`#as: -march=rv64i -mabi=lp64 -mno-relax`
			`#ld: -m[riscv_choose_lp64_emul] -Tpcrel-lo-addend-3.ld`
			`#error: .*dangerous relocation: The addend isn't allowed for R_RISCV_GOT_HI20`