You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
[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 <[email protected]>
Co-authored-by: Adrian Prantl <[email protected]>
0 commit comments