================
@@ -1344,6 +1344,35 @@ TEST_F(DWARFExpressionMockProcessTest, DW_OP_bregx) {
ExpectLoadAddress(0x2010));
}
+TEST_F(DWARFExpressionMockProcessTest, DW_OP_breg_address_size) {
+ TestContext ctx;
+ ASSERT_TRUE(
+ CreateTestContext(&ctx, "i386-pc-linux", RegisterValue(uint32_t{0x2a})));
+ ExecutionContext exe_ctx(ctx.process_sp);
+
+ // Address arithmetic wraps at the target address size. In particular,
+ // 0xffffffff + 1 is zero on this 32-bit target.
+ EXPECT_THAT_EXPECTED(
+ Evaluate({DW_OP_breg0, 0x7f, DW_OP_const4u, 0xff, 0xff, 0xff, 0xff,
+ DW_OP_plus, DW_OP_lit1, DW_OP_plus, DW_OP_stack_value},
+ {}, {}, &exe_ctx, ctx.reg_ctx_sp.get()),
+ ExpectScalar(32, 0x29, false));
+}
----------------
firmiana402 wrote:
Could we also explicitly check the result scalar's bit width?
This regression is specifically about `DW_OP_breg*` leaving a 64-bit value on a
32-bit target. `ExpectScalar(32, 0x29, false)` constructs a 32-bit expected
value, but `Scalar` equality promotes the operands before comparing them, so it
does not by itself require the actual scalar to be exactly 32 bits.
The current arithmetic sequence still catches the reported regression through
the final value, but an explicit width check would directly document and verify
the property being fixed. For example:
```cpp
auto result = Evaluate(...);
ASSERT_THAT_EXPECTED(result, ExpectScalar(32, 0x29, false));
EXPECT_EQ(result->GetScalar().GetAPSInt().getBitWidth(), 32u);
```
https://github.com/llvm/llvm-project/pull/216291
_______________________________________________
lldb-commits mailing list
[email protected]
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
