[JITLink] Allow multiple relocations at same offset in EHFrameEdgeFixer

[hahnjo]

The pass only requires that it can determine a uniquely identified target at some offsets. Multiple relocations at the same offset are fine otherwise and will be required when adding exception handling support for RISC-V.

---

This PR depends on #66707; only the top-most commit should be reviewed here.

[lhames]

Would disabling the assertion that there's a single edge in the EH-frame fixer fix the issue for now?

As a temporary fix I prefer commenting out the assertion. We could land this too, but I suspect we'll want to revert in the future and move to a design where edges support more than one target instead. I think we're gong to want to be able to say "what is the edge at this offset", then inspect the result, rather than parsing a sequence of edges at an offset to understand what's going on. We really need a proper discussion about this though.

[hahnjo]

Would disabling the assertion that there's a single edge in the EH-frame fixer fix the issue for now?

Of course, that is what https://reviews.llvm.org/D157802 originally proposed to do almost two months ago.

As a temporary fix I prefer commenting out the assertion. We could land this too, but I suspect we'll want to revert in the future and move to a design where edges support more than one target instead. I think we're gong to want to be able to say "what is the edge at this offset", then inspect the result, rather than parsing a sequence of edges at an offset to understand what's going on. We really need a proper discussion about this though.

And I personally don't like committing "temporary fixes" aka hacks. During the discussion, it became clear to me that https://reviews.llvm.org/D157802 is nothing more than a hack because the code relies on finding a uniquely identified target and the code should really check that this is possible. How would this work if a) there are multiple edges at that offset, or b) in the future there are edges with multiple targets?

[lhames]

And I personally don't like committing "temporary fixes" aka hacks.

If, as I suspect, we're going to enforce the single edge invariant in the future then this is also a temporary fix, though I'll grant you it's less of a hack. ;)

Are you happy to land this as a temporary fix for now on the understanding that it may need to be reverted, and the solution redesigned, once we come up with a long term design for LinkGraph edges?

[hahnjo]

Are you happy to land this as a temporary fix for now on the understanding that it may need to be reverted, and the solution redesigned, once we come up with a long term design for LinkGraph edges?

Yes absolutely, evolving design always needs to make sure the code is consistent. With the current design, I think the approach attempted in this PR is the most consistent we can do.

[lhames]

Perfect. In that case everything looks good to me — thanks for your patience with the review.

[hahnjo]

FWIW after 0d0f219 this PR now needs a second change to make sure there aren't already two edges for the CIE pointer field...