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.
Details
- Reviewers
uweigand labath - Commits
- rG01319e93abe3: Avoid an assertion failure when a bit field is extracted from a value of the…
rLLDB270062: 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…
Diff Detail
Event Timeline
This fixes the same issue as D19535, which is stalled at the moment waiting for a unit test. You can take over if you write a quick unit test for this (unittests/Core/ScalarTest.cpp). Thanks.
Looks good. Thank you for taking the time to add the tests. Please consider the comment below though.
Do you have commit access?
unittests/Core/ScalarTest.cpp | ||
---|---|---|
90 | Is there a reason this couldn't be written as ASSERT_EQ(a1, s_scalar.SLongLong()) ? |
Yes I do. Thanks for your review!
unittests/Core/ScalarTest.cpp | ||
---|---|---|
90 | 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. |
unittests/Core/ScalarTest.cpp | ||
---|---|---|
90 | Ok, I'll leave that up to you. |
Is there a reason this couldn't be written as ASSERT_EQ(a1, s_scalar.SLongLong()) ?
If there isn't one, I think this would make the check more readable.