| Issue |
203224
|
| Summary |
[lldb] DW_OP_implicit_value is rejected when followed by DW_OP_piece or DW_OP_bit_piece
|
| Labels |
new issue
|
| Assignees |
|
| Reporter |
firmiana402
|
## Summary
LLDB rejects legal DWARF composite location descriptions where `DW_OP_implicit_value` is wrapped in a single full-width `DW_OP_piece` or `DW_OP_bit_piece`.
These forms should be valid because the preceding location is an implicit value, so the piece should be taken from the implicit value bytes rather than treated as a memory address.
GDB accepts the same expressions and evaluates them as the expected implicit value bytes.
## Minimal Case
For example, this _expression_ should evaluate as a 4-byte implicit value:
```text
DW_OP_implicit_value 4, [0x9c 0xee 0x4c 0x86]
DW_OP_piece 4
```
Similarly, this should also be accepted:
```text
DW_OP_implicit_value 4, [0x9c 0xee 0x4c 0x86]
DW_OP_bit_piece 32, 0
```
Both are single-piece wrappers around the same implicit value.
## Actual Behavior
LLDB rejects these expressions.
For `DW_OP_piece`:
```text
failed to read memory DW_OP_piece(4) from host address ...
```
For `DW_OP_bit_piece`:
```text
unable to extract DW_OP_bit_piece(bit_size = 32, bit_offset = 0) from an address value.
```
## Expected Behavior
LLDB should preserve the implicit value bytes and allow `DW_OP_piece` / `DW_OP_bit_piece` to consume them as value content.
A single full-width piece should produce the same value bytes as the original `DW_OP_implicit_value`, matching GDB's behavior.
## Source Review Note
In [`lldb/source/_expression_/DWARFExpression.cpp`](https://github.com/llvm/llvm-project/blob/main/lldb/source/_expression_/DWARFExpression.cpp), `DW_OP_implicit_value` currently does:
```cpp
Value result(block_data.data(), block_data.size());
stack.push_back(result);
```
This uses `Value::Value(const void *bytes, int len)`, whose implementation stores the bytes in an internal buffer and classifies the value as `ValueType::HostAddress`, so the piece handlers later treat the internal LLDB buffer pointer as an address-like value instead of as the implicit bytes themselves.
As a result:
- `DW_OP_piece` tries to read memory from that host address
- `DW_OP_bit_piece` rejects it as an address value
LLDB appears to lose the distinction between "implicit value bytes" and "the host address of LLDB's temporary backing storage".
![]()
_______________________________________________
llvm-bugs mailing list
[email protected]
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
