housel added a comment. In D111863#3065992 <https://reviews.llvm.org/D111863#3065992>, @MaskRay wrote:
> I looked at the libgcc mechanism at one time. I remember that in most cases > it just uses `PT_GNU_EH_FRAME` and these eh_frame boundary registry functions > are not needed. > Can ORC just use `PT_GNU_EH_FRAME`? ORC doesn't go through the system dynamic loader, so there's no program header (JITLink doesn't generate one). None of the dynamic loaders I've looked at have any way to dynamically register program headers so that they'll be returned by `dl_iterate_phdr`. With ORC, code and data segments, including `.eh_frame` segments, get allocated in the target execution space and initialized by the JITLink memory manager, and the ORC runtime calling these registration functions is the only way libunwind will know about these tables. Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D111863/new/ https://reviews.llvm.org/D111863 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
