binutils-gdb/ld/testsuite/ld-riscv-elf/pcrel-lo-addend-3a.d
Nelson Chu 50331d64f1 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 17:14:55 +08:00

19 lines
579 B
Makefile

#source: pcrel-lo-addend-3a.s
#as: -march=rv64i -mabi=lp64 -mno-relax
#ld: -m[riscv_choose_lp64_emul] -Tpcrel-lo-addend-3.ld
#objdump: -d
#...
Disassembly of section .text:
0+900000000 <_start>:
.*:[ ]+[0-9a-f]+[ ]+lui[ ]+a5,0x2
.*:[ ]+[0-9a-f]+[ ]+ld[ ]+a0,0\(a5\) # 2000 <ll>
.*:[ ]+[0-9a-f]+[ ]+ld[ ]+a0,4\(a5\)
.*:[ ]+[0-9a-f]+[ ]+lui[ ]+a5,0x2
.*:[ ]+[0-9a-f]+[ ]+ld[ ]+a0,4\(a5\) # 2004 <ll\+0x4>
.*:[ ]+[0-9a-f]+[ ]+ld[ ]+a0,8\(a5\)
.*:[ ]+[0-9a-f]+[ ]+lui[ ]+a5,0x1
.*:[ ]+[0-9a-f]+[ ]+ld[ ]+a0,8\(a5\) # 1008 <_GLOBAL_OFFSET_TABLE_\+0x8>
#pass