RISC-V: Clarify the addends of pc-relative access.
authorNelson Chu <nelson.chu@sifive.com>
Tue, 22 Jun 2021 04:02:52 +0000 (12:02 +0800)
committerNelson Chu <nelson.chu@sifive.com>
Tue, 22 Jun 2021 09:14:55 +0000 (17:14 +0800)
commit50331d64f1080c2c9957fb608e0af236b96c1a41
tree315aae4fb8f5472c8bbdfa4a8bfeabc803b93104
parent80dc83fd0e70f4d522a534bc601df5e05b81d564
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.
bfd/ChangeLog
bfd/elfnn-riscv.c
ld/ChangeLog
ld/testsuite/ld-riscv-elf/ld-riscv-elf.exp
ld/testsuite/ld-riscv-elf/pcrel-lo-addend-3.ld [new file with mode: 0644]
ld/testsuite/ld-riscv-elf/pcrel-lo-addend-3a.d [new file with mode: 0644]
ld/testsuite/ld-riscv-elf/pcrel-lo-addend-3a.s [new file with mode: 0644]
ld/testsuite/ld-riscv-elf/pcrel-lo-addend-3b.d [new file with mode: 0644]
ld/testsuite/ld-riscv-elf/pcrel-lo-addend-3b.s [new file with mode: 0644]
ld/testsuite/ld-riscv-elf/pcrel-lo-addend-3c.d [new file with mode: 0644]
ld/testsuite/ld-riscv-elf/pcrel-lo-addend-3c.s [new file with mode: 0644]