-
Notifications
You must be signed in to change notification settings - Fork 13.5k
[JITLink][RISCV] Implement .eh_frame handling #66067
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
@llvm/pr-subscribers-backend-risc-v ChangesThis patch enables .eh_frame handling on RISC-V by using the common This mostly works out of the box but a minor change was needed for Besides this, two new edge kinds needed to be implemented for RISC-V:
|
d21b83e
to
8fec2d7
Compare
Use |
This patch enables .eh_frame handling on RISC-V by using the common `DWARFRecordSectionSplitter`, `EHFrameEdgeFixer`, and `EHFrameNullTerminator` passes. This mostly works out of the box but a minor change was needed for `EHFrameEdgeFixer`: on RISC-V, ADD/SUB relocations are used to calculate the length of a sequence of instructions when relaxation is enabled. Since both relocations are at the same offset, this caused an error to be raised by `EHFrameEdgeFixer`. I have solved this issue by simply ignoring relocations at the same offset on RISC-V. I believe this is fine since the DWARF fields where they are used (PC-range and `DW_CFA_advance_loc`) don't need any special handling. Besides this, two new edge kinds needed to be implemented for RISC-V: `Delta64` and `NegDelta32`
8fec2d7
to
836d7e7
Compare
Rebased after #66192 to fix Windows ci issues. |
@mtvec -- @hahnjo opened a similar review a while back: https://reviews.llvm.org/D157802 The |
I haven't followed the set of related discussions on this, but just to note the lack of this is currently causing a test failure in the clang-repl tests for RISC-V (seemingly a test case that was enabled by https://reviews.llvm.org/D159167). As the rv64gc qemu-user builder has been stable for a long time (i.e. only flagging actual bugs introduced by patches), I'd like to move it from the staging buildmaster, but would obviously like to see it go green before doing so. |
This test fails as .eh_frame handling is not yet implemented for RISC-V in JITLink. llvm#66067 is proposed to address this. Skip the test until the issue is resolved. It seems that D159167 enabled this test for more than just ppc64.
This test fails as .eh_frame handling is not yet implemented for RISC-V in JITLink. #66067 is proposed to address this. Skip the test until the issue is resolved. It seems that D159167 enabled this test for more than just ppc64. As the test always failed, it just wasn't run until now, I think skipping is the correct interim approach (as is already done for Arm, Darwin, and others).
Please see #68252 and #68253 for a proposal along the lines of our discussion on https://reviews.llvm.org/D157802 and https://reviews.llvm.org/D157803. It passes my very basic testing, more thorough checks would be appreciated. |
I believe this PR can be closed now, I merged #68253. |
Indeed, thanks for implementing this! |
This patch enables .eh_frame handling on RISC-V by using the common
DWARFRecordSectionSplitter
,EHFrameEdgeFixer
, andEHFrameNullTerminator
passes.This mostly works out of the box but a minor change was needed for
EHFrameEdgeFixer
: on RISC-V, ADD/SUB relocations are used to calculate the length of a sequence of instructions when relaxation is enabled. Since both relocations are at the same offset, this caused an error to be raised byEHFrameEdgeFixer
. I have solved this issue by simply ignoring relocations at the same offset on RISC-V. I believe this is fine since the DWARF fields where they are used (PC-range andDW_CFA_advance_loc
) don't need any special handling.Besides this, two new edge kinds needed to be implemented for RISC-V:
Delta64
andNegDelta32