binutils-gdb/pcrel-lo-addend-3b.d at 973563710c2f7c184fb6769e1b1d0fc5f3f181f5 - binutils-gdb - Collaboration & Inovation

mirror/binutils-gdb

mirror of https://sourceware.org/git/binutils-gdb.git synced 2024-12-09 04:21:49 +08:00

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

5 lines

203 B

Makefile

Raw Blame History

 #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