This NFC patch adds a new parameter base to functions invoked by scan_eh_tab() for calculating the address of the encoding with a relative value. base defaults to 0. This is in preparation for the AIX implementation which uses the DW_EH_PE_datarel encoding (https://reviews.llvm.org/D101298).
Details
- Reviewers
MaskRay phosek mstorsjo sfertile jasonliu cebowleratibm hubert.reinterpretcast steven_wu compnerd - Group Reviewers
Restricted Project
Diff Detail
- Repository
- rG LLVM Github Monorepo
Event Timeline
I keep feeling that the AIX implementation probably needs its own file. Making Itanium/ARM/SEH share some functions actually make generic code improvement harder.
I agree on the second part, but I don't think AIX should be split out to separate files. The AIX range table implementation which this change is meant to enable, from what I understand, is a completely straight-forward implementation of Itanium using DW_EH_PE_datarel. We would essentially be duplicating all the Itanium code for AIX with only a handful of differing lines. Splitting ARM and SEH into distinct files from Itanium might be useful, but we still need to make this exact change to the Itanium implementation.
I understand your concern. However, the AIX personality routine for the range table is essentially the same as the implementation of gxx_personality_v0 except it uses the DW_EH_PE_datarel encoding which the current Itanium implementation does not support. Therefore, this patch and the follow-on patch https://reviews.llvm.org/D101298 extend the existing Itanium implementation to allow relative addresses with a base. These two patches are straightforward and is all the AIX personality for the range table needs.
The AIX EH implementation also has a personality routine for the state table, which accounts for most changes to cxa_personality.cpp. The personality for the state table is orthogonal and can be placed in a separate file if needed.
libcxxabi/src/cxa_personality.cpp | ||
---|---|---|
922 | My idea behind splitting out an NFC patch was to have just the interface changes needed to support a datarel base implementation, without any of the functional changes for the datarel implementation. This part of the diff looks like it falls under the later. I'm guessing the intent it to show that this part of the patch is NFC for all existing targets? IMO I think we would be best with 1 interface only patch, and 1 implementation. only patch but others might disagree with me. Can you remove this, the write to exception_header->catchTemp in the bloc on lines 955-960, and then the read of exception_header->catchTemp on line 1150 to make the patch an interface change only? |
libcxxabi/src/cxa_personality.cpp | ||
---|---|---|
922 | Done. Also removed the code that gets base from cache. |
@libc++abi, @mclow.lists Hi, This NFC patch has been reviewed and approved by @sfertile but it needs the approval from blocking reviewer the libc++abi group before it can be landed. We are working on the Clang compiler for the AIX platform and libunwind/libc++abi are used for EH. For AIX, the DW_EH_PE_datarel encoding is used for calculating relative addresses in the range table. Therefore, the code for scanning the range table is extended to have one more parameter base. This NFC patch and the follow-on patch https://reviews.llvm.org/D101298 are the changes needed to process the range table for Clang on AIX. It is important to us to get the changes reviewed and landed to unblock the buildbot. It would be greatly appreciated if the group can take a look and let us know if there are any concerns.
We are also trying to replace the runtime EH implementation of the earlier compiler xlclang++ on AIX with the libc++abi/libunwind approach. Since xlclang++ uses the state table for EH instead of the range table, a separate personality routine __xlcxx_personality_v0() for the state table is implemented in cxa_personality.cpp (patch https://reviews.llvm.org/D100504). The implementation for the state table is AIX specific and orthogonal to the changes for the range table mentioned above.
I’d say wait a day or so to make sure that @ldionne doesn’t have any concerns, but this seems like it should be safe. Rebasing a pointer seems like a useful enough thing and this don’t impact the public interfaces.
TBH, cxa_personality is somewhat below what I usually touch, so I don't really have a concern here.
I'd like to note that this patch does trigger -Wunused-parameter, though - would it be possible to fix those, or are those seemingly unused parameters actually necessary to reduce the diff between upstream and a downstream fork?
TBH, cxa_personality is somewhat below what I usually touch, so I don't really have a concern here.
I'd like to note that this patch does trigger -Wunused-parameter, though - would it be possible to fix those, or are those seemingly unused parameters actually necessary to reduce the diff between upstream and a downstream fork?
Thanks for catching the unused parameter warning, @ldionne ! I will open a separate NFC patch to address it. This patch was committed yesterday morning but somehow not closed.
Commit: rG7f0244afa828: [libc++abi] NFC: adding a new parameter base to functions for calculating… (authored by xingxue). Closing.
My idea behind splitting out an NFC patch was to have just the interface changes needed to support a datarel base implementation, without any of the functional changes for the datarel implementation. This part of the diff looks like it falls under the later. I'm guessing the intent it to show that this part of the patch is NFC for all existing targets?
IMO I think we would be best with 1 interface only patch, and 1 implementation. only patch but others might disagree with me.
Can you remove this, the write to exception_header->catchTemp in the bloc on lines 955-960, and then the read of exception_header->catchTemp on line 1150 to make the patch an interface change only?