This is an archive of the discontinued LLVM Phabricator instance.

Do not patch FDE symbols in RuntimeDyld, on targets that use non-absolute symbol relocations in `.eh_frame`
AcceptedPublic

Authored by topolarity on May 24 2021, 3:12 PM.

Details

Reviewers
lhames
Summary

Since processFDE adds a delta to the values in the FDE, it assumes that the relocations for the .eh_frame section have not been applied by RuntimeDyld. It expects instead that only the relocation addend has been written to the symbol locations, and that the section-to-section offset needs to be added.

However, there are platform differences that interfere with this:

  1. X86-64 has DwarfFDESymbolsUseAbsDiff enabled in its AsmInfo, causing an absolute symbol to be emitted for the FDE pcStart. Absolute symbols are skipped as a relocation by RuntimeDyld, so the processFDE function in RuntimeDyldMachO.cpp calculates the relocation correctly.
  2. AArch64 has DwarfFDESymbolsUseAbsDiff disabled, so a relocation is emitted in the eh_frame section. Since this isn't absolute, the relocation is applied by RuntimeDyld. This means that processFDE ends up adding an additional section-to-section offset to the pcStart field, generating an incorrect FDE

Diff Detail

Event Timeline

topolarity created this revision.May 24 2021, 3:12 PM
topolarity requested review of this revision.May 24 2021, 3:12 PM
Herald added a project: Restricted Project. · View Herald TranscriptMay 24 2021, 3:12 PM

With linting this time

I also wanted to mention that there's one more barrier to getting stack unwinding working on AArch64 for JIT'd functions:

We need to force the emission of the EH Frame section (currently done via SupportsCompactUnwindWithoutEHFrame in the MCObjectFileInfo for the target), since libunwind doesn't yet support dynamically registering compact unwind information at run-time. For now I've been doing this with a simple patch to MCObjectFileInfo.cpp, commenting out the logic that enables the flag on AArch64. However, for typical JIT users, it'd probably be preferable to configure this correctly at run-time, without the compile-time patching.

Is there precedent for updating these kinds of flags/settings during the JIT setup? If so I'm happy to include that in this change, as well.

vchuravy added a project: Restricted Project.Jun 27 2021, 12:42 AM
vchuravy added a subscriber: vchuravy.
lhames accepted this revision.Jun 29 2021, 3:22 AM

The logic looks good to me. Normally I'd ask for a test case but we don't have a good way to test this at the moment, and I don't think we want to invest in RuntimeDyld testing infrastructure for MachO -- we just want to make sure this works under JITLink instead.

Speaking of which -- did you happen to check whether your test cases worked under JITLink?

  • Lang.
This revision is now accepted and ready to land.Jun 29 2021, 3:22 AM
topolarity added a comment.EditedJun 29 2021, 8:19 AM

did you happen to check whether your test cases worked under JITLink?

I checked this out briefly, but I hit a different issue for JITLink.

For some reason the .eh_frame section is empty when the EHFrameRegistrar is notified of the emitted object (EHFrameSupport.cpp:796-800), so no frames end up getting registered. When I did some debugging, it looked like the compact_unwind section is empty at that point too, so something may be preventing debug frames from being generated but I'm not sure what.

I'll try to dig further and see if I can find the root cause, but it sounds like that would be a separate fix, along with the open mentioned above about how to support forcing EH Frame generation in the JIT, at least until libunwind supports dynamic registration of compact_unwind frames.

Any updates on this, do you plan to eventually land this change? FWIW this solves one third of https://github.com/llvm/llvm-project/issues/49036

Herald added a project: Restricted Project. · View Herald TranscriptMar 11 2022, 7:35 AM

Rebasing onto trunk.