diff options
| author | Jeremy Morse <jeremy.morse@sony.com> | 2022-02-02 15:04:14 +0000 |
|---|---|---|
| committer | Jeremy Morse <jeremy.morse@sony.com> | 2022-02-02 15:08:49 +0000 |
| commit | 43de305704a50983bf134d8fb916f752a02eb076 (patch) | |
| tree | dd725a717917f9e21606aef64e9c9c2b252406ec /lldb/source/Plugins/ScriptInterpreter/Python/ScriptInterpreterPython.cpp | |
| parent | c5fff9095342a792bf4b9a077fe3c3a83c4e566c (diff) | |
[DebugInfo][InstrRef] Fix a tombstone-in-DenseMap crash from D117877
This is a follow-up to D117877: variable assignments of DBG_VALUE $noreg,
or DBG_INSTR_REFs where no value can be found, are represented by a
DbgValue object with Kind "Undef", explicitly meaning "there is no value".
In D117877 I added a special-case to some assignment accounting faster,
without considering this scenario. It causes variables to be given the
value ValueIDNum::EmptyValue, which then ends up being a DenseMap key. The
DenseMap asserts, because EmptyValue is the tombstone key.
Fix this by handling the assign-undef scenario in the special case, to
match what happens in the general case: the variable has no value if it's
only ever assigned $noreg / undef.
Differential Revision: https://reviews.llvm.org/D118715
Diffstat (limited to 'lldb/source/Plugins/ScriptInterpreter/Python/ScriptInterpreterPython.cpp')
0 files changed, 0 insertions, 0 deletions
