llvm-project

7cb84392 - [lldb] Add DWARFExpressionEntry and GetExpressionEntryAtAddress() to … (#144238)

[lldb] Add DWARFExpressionEntry and GetExpressionEntryAtAddress() to … (#144238) This patch introduces a new struct and helper API in `DWARFExpressionList` to expose variable location metadata (base address, end address, and DWARFExpression pointer) for a given PC address. It will be used in later patches to annotate disassembly instructions with source-level variable locations. ## New struct ``` /// Represents one entry in a DWARFExpressionList, with its range and expr. struct DWARFExpressionEntry { lldb::addr_t base; // file‐address start of this location range lldb::addr_t end; // file‐address end of this range (exclusive) const DWARFExpression *expr; // the DWARF expression for this range }; ``` ## New API ``` /// Retrieve the DWARFExpressionEntry covering a particular instruction. /// /// \param func_load_addr /// The load address of the start of the function containing this location list; /// used to translate between file offsets and load addresses. If this is /// LLDB_INVALID_ADDRESS, the stored CU base (m_func_file_addr) is used. /// /// \param load_addr /// The load address of the *current* PC (i.e., the instruction for which /// we want its variable‐location entry). We first convert this back into /// the function’s file‐address space to find the correct DWARF range. /// /// \returns /// On success, an entry whose `[base,end)` covers this PC; else an Error. llvm::Expected<DWARFExpressionEntry> GetExpressionEntryAtAddress(lldb::addr_t func_load_addr, lldb::addr_t load_addr) const; ``` ## Rationale LLDB already provides: ``` const DWARFExpression * GetExpressionAtAddress(lldb::addr_t func_load_addr, lldb::addr_t load_addr) const; ``` However, this only returns the DWARF expression itself, without the file‐address start (base) and end (end) of the location range. Those bounds are crucial for: 1) Detecting range beginnings: render a var = <location> annotation exactly when a variable’s live‐range starts. 2) Detecting range continuation: optionally display a “|” on subsequent instructions in the same range. 3) Detecting state changes: know when a variable moves (e.g. from one register to another), becomes a constant, or goes out of scope. These primitives form the foundation for the Rich Disassembler feature proposed for GSoC 25. --------- Co-authored-by: Jonas Devlieghere <jonas@devlieghere.com> Co-authored-by: Adrian Prantl <adrian.prantl@gmail.com>