[PATCH] D157802: [JITLink][EHFrameSupport] Accept multiple relocations

Tue Sep 19 12:16:51 PDT 2023

Hahnfeld added a comment.

In D157802#4647838 <https://reviews.llvm.org/D157802#4647838>, @jobnoorman wrote:

> In D157802#4647831 <https://reviews.llvm.org/D157802#4647831>, @Hahnfeld wrote:
>
>> I'm not proposing a general solution, just looking at the one case we need in `eh_frame` to get the PC offset from the start of the `.text` section (as far as I understand). There `ADD32` and `SUB32` are at exactly the same offset (that's the condition that currently makes `EHFrameEdgeFixer` fail) with the `SUB32` pointing to the start of the block with a zero addend. For everything else, I agree with your previous statement that storing two arbitrary symbols is a problem, and I don't think we want to go into splitting blocks to fuse edges.
>
> The problem is that those `ADD32`/`SUB32` pairs are not the only problematic relocs. There will be a lot of `SET6`/`SUB6` pairs (used for `DW_CFA_advance_loc`) at the same offset where the `SUB6` does not point to the start of a block (cf. this test case <https://github.com/llvm/llvm-project/pull/66067/files#diff-297d9308360fbf461cc8dcd59fddb4c7ff60eedb59ef54f37631e2b970d30902>).

Ah ok, I see. Then we still have one shot left to make that idea work, by only looking at relocations on offsets that need processing by `EHFrameEdgeFixer`. That would still require the `Offset32` approach because we need the keep-alive edges.

Or we just teach `EHFrameEdgeFixer` to handle multiple relocations at one offset, which gets a bit tricky which one to use for getting the correct target...

Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D157802/new/

https://reviews.llvm.org/D157802