[Lldb-commits] [PATCH] D83359: [Function] Lock the function when parsing call site info

[Vedant Kumar via Phabricator via lldb-commits]

This revision was automatically updated to reflect the committed changes.
Closed by commit rG6cfc90b9b791: [Function] Lock the function when parsing call 
site info (authored by vsk).

Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D83359/new/

https://reviews.llvm.org/D83359

Files:
  lldb/include/lldb/Symbol/Function.h
  lldb/source/Plugins/SymbolFile/DWARF/SymbolFileDWARF.cpp
  lldb/source/Symbol/Function.cpp


Index: lldb/source/Symbol/Function.cpp
===
--- lldb/source/Symbol/Function.cpp
+++ lldb/source/Symbol/Function.cpp
@@ -290,6 +290,8 @@
 }
 
 llvm::ArrayRef> Function::GetCallEdges() {
+  std::lock_guard guard(m_call_edges_lock);
+
   if (m_call_edges_resolved)
 return m_call_edges;
 
Index: lldb/source/Plugins/SymbolFile/DWARF/SymbolFileDWARF.cpp
===
--- lldb/source/Plugins/SymbolFile/DWARF/SymbolFileDWARF.cpp
+++ lldb/source/Plugins/SymbolFile/DWARF/SymbolFileDWARF.cpp
@@ -3844,6 +3844,11 @@
 
 std::vector>
 SymbolFileDWARF::ParseCallEdgesInFunction(UserID func_id) {
+  // ParseCallEdgesInFunction must be called at the behest of an exclusively
+  // locked lldb::Function instance. Storage for parsed call edges is owned by
+  // the lldb::Function instance: locking at the SymbolFile level would be too
+  // late, because the act of storing results from ParseCallEdgesInFunction
+  // would be racy.
   DWARFDIE func_die = GetDIE(func_id.GetID());
   if (func_die.IsValid())
 return CollectCallEdges(GetObjectFile()->GetModule(), func_die);
Index: lldb/include/lldb/Symbol/Function.h
===
--- lldb/include/lldb/Symbol/Function.h
+++ lldb/include/lldb/Symbol/Function.h
@@ -17,6 +17,8 @@
 #include "lldb/Utility/UserID.h"
 #include "llvm/ADT/ArrayRef.h"
 
+#include 
+
 namespace lldb_private {
 
 class ExecutionContext;
@@ -655,6 +657,9 @@
   uint32_t
   m_prologue_byte_size; ///< Compute the prologue size once and cache it
 
+  std::mutex
+  m_call_edges_lock; ///< Exclusive lock that controls read/write
+ ///  access to m_call_edges and m_call_edges_resolved.
   bool m_call_edges_resolved = false; ///< Whether call site info has been
   ///  parsed.
   std::vector> m_call_edges; ///< Outgoing call 
edges.


Index: lldb/source/Symbol/Function.cpp
===
--- lldb/source/Symbol/Function.cpp
+++ lldb/source/Symbol/Function.cpp
@@ -290,6 +290,8 @@
 }
 
 llvm::ArrayRef> Function::GetCallEdges() {
+  std::lock_guard guard(m_call_edges_lock);
+
   if (m_call_edges_resolved)
 return m_call_edges;
 
Index: lldb/source/Plugins/SymbolFile/DWARF/SymbolFileDWARF.cpp
===
--- lldb/source/Plugins/SymbolFile/DWARF/SymbolFileDWARF.cpp
+++ lldb/source/Plugins/SymbolFile/DWARF/SymbolFileDWARF.cpp
@@ -3844,6 +3844,11 @@
 
 std::vector>
 SymbolFileDWARF::ParseCallEdgesInFunction(UserID func_id) {
+  // ParseCallEdgesInFunction must be called at the behest of an exclusively
+  // locked lldb::Function instance. Storage for parsed call edges is owned by
+  // the lldb::Function instance: locking at the SymbolFile level would be too
+  // late, because the act of storing results from ParseCallEdgesInFunction
+  // would be racy.
   DWARFDIE func_die = GetDIE(func_id.GetID());
   if (func_die.IsValid())
 return CollectCallEdges(GetObjectFile()->GetModule(), func_die);
Index: lldb/include/lldb/Symbol/Function.h
===
--- lldb/include/lldb/Symbol/Function.h
+++ lldb/include/lldb/Symbol/Function.h
@@ -17,6 +17,8 @@
 #include "lldb/Utility/UserID.h"
 #include "llvm/ADT/ArrayRef.h"
 
+#include 
+
 namespace lldb_private {
 
 class ExecutionContext;
@@ -655,6 +657,9 @@
   uint32_t
   m_prologue_byte_size; ///< Compute the prologue size once and cache it
 
+  std::mutex
+  m_call_edges_lock; ///< Exclusive lock that controls read/write
+ ///  access to m_call_edges and m_call_edges_resolved.
   bool m_call_edges_resolved = false; ///< Whether call site info has been
   ///  parsed.
   std::vector> m_call_edges; ///< Outgoing call edges.
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits

[Lldb-commits] [PATCH] D83359: [Function] Lock the function when parsing call site info

[Vedant Kumar via Phabricator via lldb-commits]

vsk added inline comments.



Comment at: lldb/include/lldb/Symbol/Function.h:661
+  std::mutex
+  m_call_edges_lock; ///< Exclusive lock that controls read/write
+ ///  access to m_call_edges and m_call_edges_resolved.

aprantl wrote:
> nit: When inline comments span multiple lines it's IMO less confusing to 
> convert them to up-front comments.
> ```
>   /// Exclusive lock that controls read/write
>   /// access to m_call_edges and m_call_edges_resolved.
>   std::mutex m_call_edges_lock;
> ```
> 
> I also doubt that the ones in this file are formatted correctly, I think the 
> continuation needs to also use `///<`.
Sounds good. I'll reformat all of the data member doxygen comments in this file 
in a follow up.



Comment at: lldb/source/Symbol/Function.cpp:293
 llvm::ArrayRef> Function::GetCallEdges() {
+  std::lock_guard guard(m_call_edges_lock);
+

aprantl wrote:
> Can this be called on the same thread and would we benefit from a 
> recursive_mutex?
Function::GetCallEdges() cannot recursively call itself, so a recursive_mutex 
isn't necessary. Actually if the mutex were taken recursively, that would allow 
the m_call_edges vector to be clobbered by the n-1 GetCallEdges callers who 
took the lock before the n-th caller.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D83359/new/

https://reviews.llvm.org/D83359



___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits

[Lldb-commits] [PATCH] D83359: [Function] Lock the function when parsing call site info

[Adrian Prantl via Phabricator via lldb-commits]

aprantl accepted this revision.
aprantl added a comment.
This revision is now accepted and ready to land.

Looks plausible.




Comment at: lldb/include/lldb/Symbol/Function.h:661
+  std::mutex
+  m_call_edges_lock; ///< Exclusive lock that controls read/write
+ ///  access to m_call_edges and m_call_edges_resolved.

nit: When inline comments span multiple lines it's IMO less confusing to 
convert them to up-front comments.
```
  /// Exclusive lock that controls read/write
  /// access to m_call_edges and m_call_edges_resolved.
  std::mutex m_call_edges_lock;
```

I also doubt that the ones in this file are formatted correctly, I think the 
continuation needs to also use `///<`.



Comment at: lldb/source/Symbol/Function.cpp:293
 llvm::ArrayRef> Function::GetCallEdges() {
+  std::lock_guard guard(m_call_edges_lock);
+

Can this be called on the same thread and would we benefit from a 
recursive_mutex?


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D83359/new/

https://reviews.llvm.org/D83359



___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits