aboutsummaryrefslogtreecommitdiff
path: root/llvm/lib/CodeGen/TargetLoweringObjectFileImpl.cpp
diff options
context:
space:
mode:
authorVedant Kumar <vsk@apple.com>2020-07-07 16:54:09 -0700
committerVedant Kumar <vsk@apple.com>2020-07-09 10:37:09 -0700
commit6cfc90b9b791a023368b9384f57c2c3120894247 (patch)
tree4c4ecdaf9155f64cb7fff2e2ec7da38cda1acb05 /llvm/lib/CodeGen/TargetLoweringObjectFileImpl.cpp
parent0b72b9d07fcdf888a7020f16f8e497f1e83d2d90 (diff)
downloadllvm-6cfc90b9b791a023368b9384f57c2c3120894247.zip
llvm-6cfc90b9b791a023368b9384f57c2c3120894247.tar.gz
llvm-6cfc90b9b791a023368b9384f57c2c3120894247.tar.bz2
[Function] Lock the function when parsing call site info
Summary: DWARF-parsing methods in SymbolFileDWARF which update module state typically take the module lock. ParseCallEdgesInFunction doesn't do this, but higher-level locking within lldb::Function (which owns the storage for parsed call edges) is necessary. The lack of locking could explain some as-of-yet unreproducible crashes which occur in Function::GetTailCallingEdges(). In these crashes, the `m_call_edges` vector is non-empty but contains a nullptr, which shouldn't be possible. (If this vector is non-empty, it _must_ contain a non-null unique_ptr.) This may address rdar://55622443 and rdar://65119458. Reviewers: jasonmolenda, friss, jingham Subscribers: aprantl, lldb-commits Tags: #lldb Differential Revision: https://reviews.llvm.org/D83359
Diffstat (limited to 'llvm/lib/CodeGen/TargetLoweringObjectFileImpl.cpp')
0 files changed, 0 insertions, 0 deletions