[PATCH 1/2] RISC-V: Clarify the addends of pc-relative access.

[Jim Wilson]

On Thu, May 20, 2021 at 1:57 AM Nelson Chu <nelson.chu@sifive.com> wrote:

> The original discussion,
> 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.
>

Yes, this looks reasonable.

Besides, the %pcrel_lo and it's %pcrel_hi should be placed in the same
> input object and input section, so we don't need to record so many
> information in the struct riscv_pcrel_lo_reloc.
>

Not sure about this one.  The gcc -freorder-blocks-and-partition option can
spread a single function across 3 sections, .text, .text.hot, and
.text.unlikely.  So imagine a loop that has a memory reference.  The lui
%hi could be moved out of the loop, while the ld/sd %lo remains in the
loop.  Then the ld/sd %lo could be moved to a hot/cold text section.  That
gives you the %hi and %lo in different input sections.  This kind of thing
is hard to generate a simple testcase for though, so I'm not sure if it can
happen in practice.  If it can happen, it is probably hard to prevent the
compiler from doing this, as loop code motion and basic block reorder and
partition are different optimization passes done at different times.

it is OK to assume they are in the same input object.  I think splitting
%hi/%lo across two object files is just a bit too weird to support.

Jim