firmiana402 wrote: Updated the operand compatibility check to avoid rejecting potentially generic DWARF values based only on integer signedness; in other words, the DWARF document says that values of generic types with different signedness can be used in binary operations (e.g., `DW_OP_plus`, `DW_OP_minus`).
DWARF defines the generic type as an address-sized integral type with unspecified signedness, but in practice, the generic type must be treated as having a specific signedness in some cases. For example, the operand of `DW_OP_constu` is treated as unsigned, while the operand of `DW_OP_consts` is treated as signed. LLDB currently represents expression stack entries as `Value`/`Scalar` and does not explicitly preserve whether a value is the DWARF generic type. In addition, `DW_OP_constu`/`DW_OP_consts` do not use `to_generic` to set the operand to a generic type, but instead set it directly to `uint64`/`int64` (which is non-conforming on 32-bit systems), due to the existing compatibility issue tracked in: https://github.com/llvm/llvm-project/issues/47431. Because of that, after scalar kind and byte size already match, I updated this patch to treat integer Scalars at least as wide as the target generic type as potentially generic and does not reject them based on signedness alone. This is a compatibility approximation for LLDB's current representation. The stricter typed-operand behavior is still preserved for non-generic typed integers. For example, smaller base types such as `uint8` vs `int8` are still rejected. https://github.com/llvm/llvm-project/pull/201288 _______________________________________________ lldb-commits mailing list [email protected] https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
