One of the cases handled by ValueObjectChild::UpdateValue() uses the entire width of the parent's scalar value as the size of the child, and extracts the child by calling Scalar::ExtractBitfield(). This seems valid but APInt::trunc(), APInt::sext() and APInt::zext() assert that the bit field must not have the same size as the parent scalar. Replacing those calls with sextOrTrunc(), zextOrTrunc(), sextOrSelf() and zextOrSelf() fixes the assertion failures.
- rLLDB270062: Avoid an assertion failure when a bit field is extracted from a value of the…
rG01319e93abe3: Avoid an assertion failure when a bit field is extracted from a value of the…
rL270062: Avoid an assertion failure when a bit field is extracted from a value of the…
Looks good. Thank you for taking the time to add the tests. Please consider the comment below though.
Do you have commit access?
Is there a reason this couldn't be written as ASSERT_EQ(a1, s_scalar.SLongLong()) ?
Yes I do. Thanks for your review!
SLongLong() invokes sextOrTrunc() and getSExtValue(), potentially further changing the contents of the underlying m_integer. I felt that checking with memcmp() immediately after ExtractBitfield() is a more fool-proof way to confirm the behaviour of ExtractBitfield(). There are precedents for using memcmp() in the file, and it is not that much more unreadable.