llvm-project
f23d2ee5 - [lldb] Fix libstdc++ std::string formatter after #147835 (#152993)

Commit
227 days ago
[lldb] Fix libstdc++ std::string formatter after #147835 (#152993) https://github.com/llvm/llvm-project/pull/147835 made changes that caused libstdc++ std::string tests to fail: ``` ====================================================================== FAIL: test_unavailable_summary_libstdcxx_dwo (TestDataFormatterStdString.StdStringDataFormatterTestCase) ---------------------------------------------------------------------- Traceback (most recent call last): File "/home/tcwg-buildbot/worker/lldb-aarch64-ubuntu/llvm-project/lldb/packages/Python/lldbsuite/test/lldbtest.py", line 1805, in test_method return attrvalue(self) File "/home/tcwg-buildbot/worker/lldb-aarch64-ubuntu/llvm-project/lldb/test/API/functionalities/data-formatter/data-formatter-stl/generic/string/TestDataFormatterStdString.py", line 223, in test_unavailable_summary_libstdcxx self.do_test_summary_unavailable() File "/home/tcwg-buildbot/worker/lldb-aarch64-ubuntu/llvm-project/lldb/test/API/functionalities/data-formatter/data-formatter-stl/generic/string/TestDataFormatterStdString.py", line 213, in do_test_summary_unavailable self.assertEqual(summary, "Summary Unavailable", "No summary for bad value") AssertionError: '(null)' != 'Summary Unavailable' - (null) + Summary Unavailable : No summary for bad value Config=aarch64-/home/tcwg-buildbot/worker/lldb-aarch64-ubuntu/build/bin/clang ---------------------------------------------------------------------- ``` This test constructs an invalid std::string by starting with a null pointer. Somehow this improvement in Clang uncovered a bug in the formatter. Perhaps because we now know the type of the field we tried to access is char *, so fall back to a C string formatter that produces `(null)`. The formatter tries to access `_M_p` and checked whether the resulting ValueObjectSP was null, but not that it did not contain an error value. I think that error value can be there if you are able to access one part of the path, `_M_dataplus`, but another part fails. Since the layout looks like this: ``` struct _Alloc_hider : { pointer _M_p; // The actual data. }; _Alloc_hider _M_dataplus; void _M_data(pointer __p) { _M_dataplus._M_p = __p; } ``` So I think we were able to read `_M_dataplus` just by offset, but then failed because it contains, or points to something containing nulls or a null pointer. Or perhaps an error value means we know what the class member is, but could not read from it. I found this by comparing with the libcxx formatter, so I've copied the same handling from there to fix the issue.
Author
Parents
Loading