mirror of
https://github.com/capstone-engine/llvm-capstone.git
synced 2025-02-25 13:05:04 +00:00
f09f0a6b10
This rewrites DW_OP_addrx inside DWARFExpression as an DW_OP_addr so that we can update addresses that are originally located in the debug_addr section. The full discussion behind this can be found in https://discourse.llvm.org/t/dwarfexpression-and-dw-op-addrx/71627/12, but a summary follows. When SymbolFileDWARF::ParseVariableDIE creates DWARFExpressions for variables whose location is an OP_addr, it knows how to remap addresses appropriately in the DebugMap case. It then calls DWARFExpression::Update_DW_OP_addr, which updates the value associated with OP_addr. However, when we have an OP_addrx, the update function does nothing. This makes sense, as the DWARFExpression does not have a mutable view of the debug_addr section. In non-DebugMap flows this is not an issue, as the debug_addr contains the correct addresses of variables. In DebugMap flows, this is problematic because the work done by RelinkOSOAddress is lost. By updating the OP to OP_addr, we can also update the address as required, We also explored the alternative of relinking the debug_addr section when we are initializing OSOs (InitOSO). However, this creates an inconsistent story for users of DWARFExpression::GetLocation_DW_OP_addr. This function returns an address without telling callers whether that address came from an OP_addr or an OP_addrx. If we preemptively relink OP_addrx results without doing the same for OP_addr results, then callers can’t know whether the address they got was an executable address or an object file address. In other words, they can’t know whether they need to call LinkOSOFileAddress on those results or not. This patch addresses the majority of test failures when enabling DWARF 5 for MachO (over 200 test failures). Differential Revision: https://reviews.llvm.org/D155198