binutils-gdb/ld/testsuite/ld-riscv-elf/pcrel-lo-addend-3a.s

	.text
	.globl _start
	.align 3
_start:
.LA0:	auipc	a5, %pcrel_hi (ll)
	ld	a0, %pcrel_lo (.LA0)(a5)
	ld	a0, %pcrel_lo (.LA0 + 0x4)(a5)

.LA1:	auipc	a5, %pcrel_hi (ll + 0x4)
	ld	a0, %pcrel_lo (.LA1)(a5)
	ld	a0, %pcrel_lo (.LA1 + 0x4)(a5)

.LA2:	auipc	a5, %got_pcrel_hi (ll)
	ld	a0, %pcrel_lo (.LA2)(a5)

	.globl ll
	.data
ll:
	.dword	0
	.dword	0
	.dword	0
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			`.text`
			`.globl _start`
			`.align 3`
			`_start:`
			`.LA0: auipc a5, %pcrel_hi (ll)`
			`ld a0, %pcrel_lo (.LA0)(a5)`
			`ld a0, %pcrel_lo (.LA0 + 0x4)(a5)`

			`.LA1: auipc a5, %pcrel_hi (ll + 0x4)`
			`ld a0, %pcrel_lo (.LA1)(a5)`
			`ld a0, %pcrel_lo (.LA1 + 0x4)(a5)`

			`.LA2: auipc a5, %got_pcrel_hi (ll)`
			`ld a0, %pcrel_lo (.LA2)(a5)`

			`.globl ll`
			`.data`
			`ll:`
			`.dword 0`
			`.dword 0`
			`.dword 0`