forked from OSchip/llvm-project
14135f50a0
Value::GetValueByteSize() reports the size of a Value as the size of its underlying CompilerType. However, a host buffer that backs a Value may be smaller than GetValueByteSize(). This situation arises when the host is only able to partially evaluate a Value, e.g. because the expression contains DW_OP_piece. The cleanest fix I've found to this problem is Greg's suggestion, which is to resize the Value if (after evaluating an expression) it's found to be too small. I've tried several alternatives which all (in one way or the other) tried to teach the Value/ValueObjectChild system not to read past the end of a host buffer, but this was flaky and impractical as it isn't easy to figure out the host buffer's size (Value::GetScalar() can point to somewhere /inside/ a host buffer, but you need to walk up the ValueObject hierarchy to try and find its size). This fixes an ASan error in lldb seen when debugging a clang binary. I've added a regression test in test/functionalities/optimized_code. The point of that test is not specifically to check that DW_OP_piece is handled a particular way, but rather to check that lldb doesn't crash on an input that it used to crash on. Testing: check-lldb, and running the added tests using a sanitized lldb -- Thanks to Jim for pointing out that an earlier version of this patch, which simply changed the definition of Value::GetValueByteSize(), would interact poorly with the ValueObject machinery. Thanks also to Pavel who suggested a neat way to test this change (which, incidentally, caught another ASan issue still present in the original version of this patch). rdar://58665925 Differential Revision: https://reviews.llvm.org/D73148 |
||
---|---|---|
.. | ||
API | ||
Shell | ||
Unit | ||
CMakeLists.txt | ||
lit.cfg.py | ||
lit.site.cfg.py.in |