[Lldb-commits] [lldb] [LLDB] fix lldb breg adress width (PR #216291)

[via lldb-commits]

================
@@ -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