[PATCH] D157802: [JITLink][EHFrameSupport] Accept multiple relocations
Jonas Hahnfeld via Phabricator via llvm-commits
llvm-commits at lists.llvm.org
Mon Aug 14 01:47:31 PDT 2023
Hahnfeld added a comment.
In D157802#4583708 <https://reviews.llvm.org/D157802#4583708>, @lhames wrote:
>> Multiple relocations at one offset are fine, for example RISC-V uses it in FDE's.
>
> That's interesting. Are all relocations that share an offset identical? (same type, target, etc.)
No, they are different types (`ADD` and `SUB`) with different targets. I would have to look up the details, but you should be able to get an idea by looking at the test case in https://reviews.llvm.org/D157803. I *assume* that, because RISC-V doesn't have a specific delta relocation, CodeGen has to build it up by combining `ADD` and `SUB` relocations?
> If not, are we really free to ignore the others?
I don't know. As far as I can tell, they are on a field of the FDE that the `EHFrameEdgeFixer` never looks at; but `BlockEdges` gathers all edges in the block, not only the ones that we need.
> I'm particularly interested because I've thought about enforcing such a uniqueness constraint at the `LinkGraph` level: no more than one edge at a given offset. I had assumed that this would be safe, but it sounds like this may not work for RISCV graphs.
No, this certainly will not work on RISC-V, also because of linker relaxation that works by having multiple relocations at the same offset.
> As for `BlockEdges`, it's dealing with a quirk that I think only applies to MachO: On some architectures, notably x86-64, the `__eh_frame` section doesn't have explicit relocations for some fields. Instead, the target is implied by the initial values of the CIE / FDE fields and the linker has to recreate the edges from that. BlockEdges I used to track which fields (if any) have explicit edges already so that the others can be created.
Ah ok, thanks for that explanation. So `EHFrameEdgeFixer` is maybe not needed at all on ELF? Or maybe we can split the part that is specific to MachO into a separate pass that explicitly does what is needed instead of `getOrCreateEncodedPointerEdge`?
Repository:
rG LLVM Github Monorepo
CHANGES SINCE LAST ACTION
https://reviews.llvm.org/D157802/new/
https://reviews.llvm.org/D157802
More information about the llvm-commits
mailing list