| Issue |
202897
|
| Summary |
[lldb] lldb zero-fills unavailable DW_OP_piece fragments instead of preserving optimized-out state
|
| Labels |
new issue
|
| Assignees |
|
| Reporter |
firmiana402
|
LLDB currently materializes an unavailable `DW_OP_piece` fragment as concrete zero bytes.
That loses the fact that the fragment is unavailable and can turn a partially optimized-out composite location into an invented concrete value.
I am using a DWARF _expression_ directly here because it is easier to understand and maps directly to the DWARF location-description rules.
A simple example illustrating the behavior is:
```text
DW_OP_piece 1
DW_OP_const1s -1
DW_OP_stack_value
DW_OP_piece 3
```
This should be read as a composite location with an unavailable leading 1-byte fragment and a concrete trailing 3-byte fragment whose bytes are `0xff`.
So the result should preserve partial unavailability. It should not invent a fully concrete 4-byte integer value.
GDB preserves that distinction and reports the affected fragment as `<optimized out>`.
LLDB instead materializes the unavailable byte as `0x00`. On a little-endian target, that turns the 4-byte value into `0xffffff00`, which is the concrete integer `-256`.
That is not just a presentation difference. It changes an unavailable fragment into a made-up concrete value.
So the unavailable leading fragment is not merely displayed differently; LLDB turns it into a concrete byte pattern and reports a wrong value.
While reviewing [lldb/source/_expression_/DWARFExpression.cpp](https://github.com/llvm/llvm-project/blob/main/lldb/source/_expression_/DWARFExpression.cpp), specifically `Evaluate_DW_OP_piece`, I noticed that the empty-stack piece path does exactly this:
- it treats the current piece as "not available."
- it resizes the piece buffer
- it fills the buffer with zeros using `memset(...)`
The source comment immediately below already says:
> "0" is not a correct value for the unknown bits.
So the current behavior appears to be a known placeholder that leaks into user-visible evaluation results.
![]()
_______________________________________________
llvm-bugs mailing list
[email protected]
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
