Should we constrain the target label of a %pcrel_lo to be in the same section? about riscv-elf-psabi-doc HOT 15 CLOSED

I was more worried about the original poster :). @rofirrim: do you have a use case for putting them in different sections?

from riscv-elf-psabi-doc.

LLD does handle OP's case correctly since it scans relocations from all input sections into its own data structure first before performing actual relocations, so it is easy to find the corresponding R_RISCV_PCREL_HI20 just by searching for relocations for the HI20-symbol's section. Therefore I think it is more of an limitation of ld.

If we can't find a valid use case for this I'm okay with forbidding it in the ABI to simplify the implementations. It is always possible to relax this requirement afterwards if needed.

from riscv-elf-psabi-doc.

My inclination is that this behavior should be OK, and the linker should not emit an error. But I haven't thought through the implications on linker relaxation, which might for some reason favor the hi/lo relocs being in the same section.

from riscv-elf-psabi-doc.

​GNU ld relocates one section at a time. It is while we are relocating a section that we match pcrel_lo relocs to pcrel_hi relocs. In order to resolve a pcrel_lo reloc, we need both the address of the pcrel_hi reloc which is part of the pcrel_lo reloc, and the address of the symbol that the pcrel_hi reloc points to, which is part of the pcrel_hi reloc. So we have to find the matching pcrel_hi reloc to resolve a pcrel_lo reloc. As we scan through the section resolving relocs, we record all of the pcrel_hi and pcrel_lo relocs we see, then match them together at the end to resolve them. And we do this one section at time. Hence, the current GNU ld implementation requires that matching pcrel_hi and pcrel_lo relocs are in the same section.

There might be a way to fix GNU ld to make this work, but linkers are complicated, and someone would have to spend some time looking at GNU ld to figure out how to fix it.

The easiest solution to make this work might be an ABI change. If we had something like
addi a1, a0, %lo(bar,label)
and then emit a reloc with two symbols in it, or emit two relocs one with a symbol address to add and one with a symbol address to subtract, then we wouldn't need to find the matching %pcrel_hi reloc. But this probably requires other cascading ABI changes, and might require changes to how relaxation works, and is likely still a lot of work.

Meanwhile, in the short term, the only thing I can easily do is document this as a limitation of GNU ld.

from riscv-elf-psabi-doc.

Is there a use case for having the lo/hi in separate sections? If not then I think we should just leave this as a GNU ld limitation rather than trying to add a new relocation to handle it. I wouldn't be opposed to just mandating they're in the same section in the ABI.

from riscv-elf-psabi-doc.

I didn’t realize supporting this would be so involved. I don’t have a use case in mind, and I agree we should either document it in the ABI or in the LD docs as an LD limitation.

from riscv-elf-psabi-doc.

Thanks everyone for all the insightful comments so far. I'm afraid I don't have a realistic use case.

The context is that in the RISC-V backend of LLVM, when not expecting the linker to relax, we can solve some addresses in the assembler backend itself, thus removing the relocation in the final object.

%pcrel_hi / %pcrel_lo pairs must be handled carefully because we can't keep a %pcrel_lo if we have already decided to remove its corresponding %pcrel_hi (this issue is already happening in a few circumstances).

One of the patches being proposed to address is doing a "section-wise" process (https://reviews.llvm.org/D58843) which I understand wouldn't be quite right in my original example: we risk removing a %pcrel_hi because no other users (%pcrel_lo) of it in the same section exist.

My question was more theoretical, in like "can we rely on this?". From the answers above, I see how disallowing this case would simplify tooling and make an approach like the one being proposed in LLVM reasonable.

from riscv-elf-psabi-doc.

In the absence of a compelling use case for pcrle_hi/pcrel_lo pairs crossing sections, I'm in favour of forbidding in the ABI.

from riscv-elf-psabi-doc.

I'm in favor of removing it as well. Unless there's any objections in a week let's merge the suggested change. @rofirrim: do you want to open a PR, or do you want me to?

from riscv-elf-psabi-doc.

@kito-cheng: any opinions? IIRC you guys have some non-standard ELF ABI stuff floating around, but I'm assuming you don't split pcrel_lo/pcrel_hi relocations into different sections.

from riscv-elf-psabi-doc.

I also opened a sw-dev thread: https://groups.google.com/a/groups.riscv.org/forum/#!topic/sw-dev/CUQ4V7Xp35E

from riscv-elf-psabi-doc.

I'm OK to forbid that too, we only added simple relocation for single instruction in our non-standard ELF ABI stuff.

Cross section might cause problem in corner case, because the relative distance might increase after relaxation if some sections are start at fixed address, and then got a relocation truncate to fit error, so forbid that could save some problem in future.

from riscv-elf-psabi-doc.

If I'm reading this right, GNU ld already implements this restriction, so Fedora & Debian should be safe and unaffected by this change?

from riscv-elf-psabi-doc.

Yes, Fedora and Debian are unaffected by this.

from riscv-elf-psabi-doc.

This feature might be useful for hot/cold partitioning. This is done by gcc with the -freorder-blocks-and-partition optimization option, which is not enabled by default for RISC-V, but is enabled by default for x86 targets with -Os and -O2 and higher. In theory, this testcase could be generated by this optimization option, but it might take a contrived example to force this to happen.

There is another gcc issue here in that we only emit pcrel_hi/pcrel_lo if you use -fexplicit-relocs, and this is not enabled by default because it is known to fail in some cases. It is also not recommended for use for the same reason. Currently, gcc only emits lla and lets the assembler generate the auipc and addi which will always be adjacent and in the same section.

So with the GNU toolchain, we would need two uncommon non-default optimizations to have a chance at triggering the GNU ld problem.

Kito mentioned relaxation, but we relax all sections before we enter the loop to relocate each section, so I don't think that this should be a problem.

from riscv-elf-psabi-doc.