labath added a comment.
I'm seeing some very funky behavior after this patch. My machine has both
libc++ and libstdc++, so both versions of this test run normally, and then
libstdc++ fails. If I run just the libstdc++ version then it passes just fine.
If I change the test order so that the libstdc++ version is run first, then the
*libc++* version fails instead...
================
Comment at: lldb/examples/synthetic/gnu_libstdcpp.py:25
+ self.value = self.payload.GetChildMemberWithName('_M_payload')
+ self.count =
self.payload.GetChildMemberWithName('_M_engaged').GetValueAsUnsigned(0)
+ except:
----------------
I assume this is relying on the fact that `_M_engaged` can only contain values
1 and 0. While this may be true for normal situations, people tend to use
debuggers precisely in the situations where things are not "normal". And it'd
be good if e.g. a user's memory corruption bug (which for example overwrites
this field) does not make the debugger go haywire. You most likely cannot
format the value correctly if that happens, but you can at least avoid printing
3195786238 children in those cases.
One way to do that would be to rename this field to `engaged` and implement the
num_children method as `return self.engaged ? 1 : 0`
================
Comment at: lldb/source/API/SBValue.cpp:1442
+ return lldb::SBValue(value_sp->Clone(ConstString(new_name)));
+ else
+ return lldb::SBValue();
----------------
https://llvm.org/docs/CodingStandards.html#don-t-use-else-after-a-return
Repository:
rG LLVM Github Monorepo
CHANGES SINCE LAST ACTION
https://reviews.llvm.org/D114403/new/
https://reviews.llvm.org/D114403
_______________________________________________
lldb-commits mailing list
[email protected]
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
