| Issue |
202878
|
| Summary |
[lldb] Wrong signedness when evaluating DW_OP_lt/le/gt/ge for generic types
|
| Labels |
|
| Assignees |
|
| Reporter |
firmiana402
|
## Summary
In [DWARF v5](https://dwarfstd.org/doc/DWARF5.pdf), the generic type has unspecified signedness in general, but Section 2.5.1.5 explicitly requires generic relational comparisons to be performed as **signed** operations.
LLDB currently evaluates generic `DW_OP_lt`, `DW_OP_le`, `DW_OP_gt`, and `DW_OP_ge` through ordinary `Scalar` comparisons instead. As a result, the outcome depends on the incidental signedness attached to the current `Scalar` representation, rather than on the DWARF rule for generic relational operators.
I am using a raw DWARF _expression_ here because the bug is in DWARF-_expression_ evaluation semantics itself, and the reduced form is clearer than a source reproducer.
One minimal example is:
```text
DW_OP_const8u 0xffffffffffffffff
DW_OP_consts 0
DW_OP_lt
DW_OP_stack_value
```
On a 64-bit target, both values are generic. Under DWARF, generic relational comparisons are signed, so this should be interpreted as:
```text
-1 < 0
```
and therefore evaluate to `1`.
GDB evaluates this _expression_ correctly and produces `1`.
LLDB produces `0`, which is consistent with treating the first operand as unsigned `UINT64_MAX` instead of signed `-1`.
While reviewing [lldb/source/_expression_/DWARFExpression.cpp](https://github.com/llvm/llvm-project/blob/main/lldb/source/_expression_/DWARFExpression.cpp) and [lldb/source/Utility/Scalar.cpp](https://github.com/llvm/llvm-project/blob/main/lldb/source/Utility/Scalar.cpp), I noticed the following pattern:
- generic values are materialized through `Scalar`; the current code comment even says to "just use the signedness of the operand".
- `DW_OP_lt/le/gt/ge` directly dispatch to `Scalar` comparison operators
- `Scalar` comparison uses its own promotion and `APSInt` signedness rules
So the DWARF-specific signed-comparison rule for generic relational operators appears to get lost.
## Affected DWARF Opcodes
The same root cause was for:
- `DW_OP_lt`
- `DW_OP_le`
- `DW_OP_gt`
- `DW_OP_ge`
![]()
_______________________________________________
llvm-bugs mailing list
[email protected]
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
