[Lldb-commits] [PATCH] D125325: Pass plugin_name in SBProcess::SaveCore

2022-05-11 Thread Levon Ter-Grigoryan via Phabricator via lldb-commits 
PatriosTheGreat updated this revision to Diff 428577.
PatriosTheGreat edited the summary of this revision.

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

https://reviews.llvm.org/D125325

Files:
  lldb/bindings/interface/SBProcess.i
  lldb/include/lldb/API/SBProcess.h
  lldb/source/API/SBProcess.cpp


Index: lldb/source/API/SBProcess.cpp
===
--- lldb/source/API/SBProcess.cpp
+++ lldb/source/API/SBProcess.cpp
@@ -1138,6 +1138,12 @@
 
 lldb::SBError SBProcess::SaveCore(const char *file_name) {
   LLDB_INSTRUMENT_VA(this, file_name);
+  return SaveCore(file_name, "");
+}
+
+lldb::SBError SBProcess::SaveCore(const char *file_name,
+  const char *plugin_name) {
+  LLDB_INSTRUMENT_VA(this, file_name, plugin_name);
 
   lldb::SBError error;
   ProcessSP process_sp(GetSP());
@@ -1156,7 +1162,8 @@
 
   FileSpec core_file(file_name);
   SaveCoreStyle core_style = SaveCoreStyle::eSaveCoreFull;
-  error.ref() = PluginManager::SaveCore(process_sp, core_file, core_style, "");
+  error.ref() = PluginManager::SaveCore(process_sp, core_file, core_style,
+plugin_name);
   return error;
 }
 
Index: lldb/include/lldb/API/SBProcess.h
===
--- lldb/include/lldb/API/SBProcess.h
+++ lldb/include/lldb/API/SBProcess.h
@@ -338,6 +338,9 @@
   bool IsInstrumentationRuntimePresent(InstrumentationRuntimeType type);
 
   /// Save the state of the process in a core file (or mini dump on Windows).
+  lldb::SBError SaveCore(const char *file_name, const char *plugin_name);
+
+  // Save the state of the process with the default plugin.
   lldb::SBError SaveCore(const char *file_name);
 
   /// Query the address load_addr and store the details of the memory
Index: lldb/bindings/interface/SBProcess.i
===
--- lldb/bindings/interface/SBProcess.i
+++ lldb/bindings/interface/SBProcess.i
@@ -397,6 +397,9 @@
 bool
 IsInstrumentationRuntimePresent(lldb::InstrumentationRuntimeType type);
 
+lldb::SBError
+SaveCore(const char *file_name, const char *plugin_name);
+
 lldb::SBError
 SaveCore(const char *file_name);
 


Index: lldb/source/API/SBProcess.cpp
===
--- lldb/source/API/SBProcess.cpp
+++ lldb/source/API/SBProcess.cpp
@@ -1138,6 +1138,12 @@
 
 lldb::SBError SBProcess::SaveCore(const char *file_name) {
   LLDB_INSTRUMENT_VA(this, file_name);
+  return SaveCore(file_name, "");
+}
+
+lldb::SBError SBProcess::SaveCore(const char *file_name,
+  const char *plugin_name) {
+  LLDB_INSTRUMENT_VA(this, file_name, plugin_name);
 
   lldb::SBError error;
   ProcessSP process_sp(GetSP());
@@ -1156,7 +1162,8 @@
 
   FileSpec core_file(file_name);
   SaveCoreStyle core_style = SaveCoreStyle::eSaveCoreFull;
-  error.ref() = PluginManager::SaveCore(process_sp, core_file, core_style, "");
+  error.ref() = PluginManager::SaveCore(process_sp, core_file, core_style,
+plugin_name);
   return error;
 }
 
Index: lldb/include/lldb/API/SBProcess.h
===
--- lldb/include/lldb/API/SBProcess.h
+++ lldb/include/lldb/API/SBProcess.h
@@ -338,6 +338,9 @@
   bool IsInstrumentationRuntimePresent(InstrumentationRuntimeType type);
 
   /// Save the state of the process in a core file (or mini dump on Windows).
+  lldb::SBError SaveCore(const char *file_name, const char *plugin_name);
+
+  // Save the state of the process with the default plugin.
   lldb::SBError SaveCore(const char *file_name);
 
   /// Query the address load_addr and store the details of the memory
Index: lldb/bindings/interface/SBProcess.i
===
--- lldb/bindings/interface/SBProcess.i
+++ lldb/bindings/interface/SBProcess.i
@@ -397,6 +397,9 @@
 bool
 IsInstrumentationRuntimePresent(lldb::InstrumentationRuntimeType type);
 
+lldb::SBError
+SaveCore(const char *file_name, const char *plugin_name);
+
 lldb::SBError
 SaveCore(const char *file_name);
 
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits

[Lldb-commits] [PATCH] D125325: Pass plugin_name in SBProcess::SaveCore

2022-05-11 Thread Levon Ter-Grigoryan via Phabricator via lldb-commits 
PatriosTheGreat marked 3 inline comments as done.
PatriosTheGreat added a comment.

Hi Greg.

Thanks for the review.
I fixed the feedback.
I forgot the default initialization of plugin_name parameter in SBProcess.i in 
previous version, but I assume it's still better to explicitly create a 
separate method.


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

https://reviews.llvm.org/D125325

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

[Lldb-commits] [PATCH] D124858: [trace][intelpt] Support system-wide tracing [4] - Support per core tracing on lldb-server

2022-05-11 Thread Jakob Johnson via Phabricator via lldb-commits 
jj10306 accepted this revision.
jj10306 added a comment.
This revision is now accepted and ready to land.

couple minor things, but looks good overall




Comment at: lldb/docs/lldb-gdb-remote.txt:465-474
 //  "tid": ,
 //  "binaryData": [
 //{
 //  "kind": ,
 //  Identifier for some binary data related to this thread to
 //  fetch with the jLLDBTraceGetBinaryData packet.
 //  "size": ,

wallace wrote:
> wallace wrote:
> > jj10306 wrote:
> > > Should the thread info be optional now that we have an optional `cores`? 
> > > If not, can you explain how this output works in the case that you are 
> > > doing per core tracing? Will both the tid binary data and the cores 
> > > binary data section be populated?
> > I'll make this field optional and include more documentation below
> in the end i didn't make this optional but instead forced the per-core case 
> to return all threads 
so the tid field of a tracedThread object will be populated but the binaryData 
will not be populated in the tracedThread object but instead in the cores 
section?



Comment at: lldb/source/Plugins/Process/Linux/Perf.h:119
   ///
   /// \param[in] group_fd
+  /// File descriptor of the group leader. \b -1 indicated that this

nit: we could make this optional as well and just default to passing in -1 to 
be consistent with cpu and pid



Comment at: lldb/source/Utility/TraceGDBRemotePackets.cpp:124
+json::Value toJSON(const TraceCoreState &packet) {
+  return json::Value(Object{{"coreId", static_cast(packet.core_id)},
+{"binaryData", packet.binary_data}});

isn't uint64_t serialization and deserialization now supported?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D124858

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

[Lldb-commits] [PATCH] D124858: [trace][intelpt] Support system-wide tracing [4] - Support per core tracing on lldb-server

2022-05-11 Thread Jakob Johnson via Phabricator via lldb-commits 
jj10306 added inline comments.



Comment at: lldb/source/Plugins/Process/Linux/IntelPTCollector.h:152-156
+  IntelPTPerThreadProcessTraceUP m_per_thread_process_trace_up;
+  /// Cores traced due to per-core "process tracing". Only one active
+  /// "process tracing" instance is allowed for a single process.
+  /// This might be \b nullptr.
+  IntelPTMultiCoreTraceUP m_per_core_process_trace_up;

wallace wrote:
> jj10306 wrote:
> > So these are mutually exclusive tight?
> yes, I'll leave a comment about that here
this could be overkill, but potentially we could use a union here to enforce 
this invariant and a boolean flag/enum to determine which process tracing 
"handler" is being used
```
bool is_per_core_process_tracing_enabled; // used to determine how to interpret 
the union
union {
  IntelPTPerThreadProcessTraceUP m_per_thread_process_trace_up;
  IntelPTMultiCoreTraceUP m_per_core_process_trace_up;

};
```
imo this is much more clearly expresses the invariant of only one of the 
process tracing "handles" being non null at a time.
wdyt?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D124858

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

[Lldb-commits] [PATCH] D125047: [trace][intelpt] Support system-wide tracing [6] - Break IntelPTCollector into smaller files and minor refactor

2022-05-11 Thread Jakob Johnson via Phabricator via lldb-commits 
jj10306 accepted this revision.
jj10306 added inline comments.
This revision is now accepted and ready to land.



Comment at: lldb/source/Utility/TraceGDBRemotePackets.cpp:136
 {"tid", packet.tid},
-{"size", packet.size}});
+{"size", static_cast(packet.size)}});
 }

why is this needed now? I thought that unsigned ints were now supported by the 
json lib. 
is this temporary because of the bug you address in D125322?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D125047

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

[Lldb-commits] [PATCH] D124731: [lldb] Consider binary as module of last resort

2022-05-11 Thread Will Hawkins via Phabricator via lldb-commits 
hawkinsw added a comment.

Sorry to bother you all (@jingham, @JDevlieghere  and @labath), but I just 
wondered if there was anything else that I could do to spruce this up! I want 
to make sure that it meets everyone's expectations! It's been awesome to work 
on this submission!

Will


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D124731

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

[Lldb-commits] [PATCH] D124858: [trace][intelpt] Support system-wide tracing [4] - Support per core tracing on lldb-server

2022-05-11 Thread walter erquinigo via Phabricator via lldb-commits 
wallace added inline comments.



Comment at: lldb/docs/lldb-gdb-remote.txt:465-474
 //  "tid": ,
 //  "binaryData": [
 //{
 //  "kind": ,
 //  Identifier for some binary data related to this thread to
 //  fetch with the jLLDBTraceGetBinaryData packet.
 //  "size": ,

jj10306 wrote:
> wallace wrote:
> > wallace wrote:
> > > jj10306 wrote:
> > > > Should the thread info be optional now that we have an optional 
> > > > `cores`? If not, can you explain how this output works in the case that 
> > > > you are doing per core tracing? Will both the tid binary data and the 
> > > > cores binary data section be populated?
> > > I'll make this field optional and include more documentation below
> > in the end i didn't make this optional but instead forced the per-core case 
> > to return all threads 
> so the tid field of a tracedThread object will be populated but the 
> binaryData will not be populated in the tracedThread object but instead in 
> the cores section?
yes, exactly



Comment at: lldb/source/Plugins/Process/Linux/IntelPTCollector.h:152-156
+  IntelPTPerThreadProcessTraceUP m_per_thread_process_trace_up;
+  /// Cores traced due to per-core "process tracing". Only one active
+  /// "process tracing" instance is allowed for a single process.
+  /// This might be \b nullptr.
+  IntelPTMultiCoreTraceUP m_per_core_process_trace_up;

jj10306 wrote:
> wallace wrote:
> > jj10306 wrote:
> > > So these are mutually exclusive tight?
> > yes, I'll leave a comment about that here
> this could be overkill, but potentially we could use a union here to enforce 
> this invariant and a boolean flag/enum to determine which process tracing 
> "handler" is being used
> ```
> bool is_per_core_process_tracing_enabled; // used to determine how to 
> interpret the union
> union {
>   IntelPTPerThreadProcessTraceUP m_per_thread_process_trace_up;
>   IntelPTMultiCoreTraceUP m_per_core_process_trace_up;
> 
> };
> ```
> imo this is much more clearly expresses the invariant of only one of the 
> process tracing "handles" being non null at a time.
> wdyt?
I tried this, but using unions with complex types requires some non-trivial 
work. std::variant would be a good choice but is not available in the c++ 
version used by llvm. So in this case I think the current implementation is the 
simpler. However, I'd rather create an interface and have one single instance 
based on that interface. I'll try that



Comment at: lldb/source/Plugins/Process/Linux/Perf.h:119
   ///
   /// \param[in] group_fd
+  /// File descriptor of the group leader. \b -1 indicated that this

jj10306 wrote:
> nit: we could make this optional as well and just default to passing in -1 to 
> be consistent with cpu and pid
good idea



Comment at: lldb/source/Utility/TraceGDBRemotePackets.cpp:124
+json::Value toJSON(const TraceCoreState &packet) {
+  return json::Value(Object{{"coreId", static_cast(packet.core_id)},
+{"binaryData", packet.binary_data}});

jj10306 wrote:
> isn't uint64_t serialization and deserialization now supported?
good catch


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D124858

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

[Lldb-commits] [PATCH] D124858: [trace][intelpt] Support system-wide tracing [4] - Support per core tracing on lldb-server

2022-05-11 Thread walter erquinigo via Phabricator via lldb-commits 
wallace updated this revision to Diff 428687.
wallace added a comment.

address comments

In a newer diff I'll create a base class for all "process tracing" strategies, 
so that we don't need to use two unique pointers for both process tracing 
classes in the collector. I'm not doing it here becaues rebasing would be a 
pain.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D124858

Files:
  lldb/docs/lldb-gdb-remote.txt
  lldb/include/lldb/Utility/TraceGDBRemotePackets.h
  lldb/include/lldb/Utility/TraceIntelPTGDBRemotePackets.h
  lldb/include/lldb/lldb-types.h
  lldb/packages/Python/lldbsuite/test/tools/intelpt/intelpt_testcase.py
  lldb/source/Plugins/Process/Linux/CMakeLists.txt
  lldb/source/Plugins/Process/Linux/IntelPTCollector.cpp
  lldb/source/Plugins/Process/Linux/IntelPTCollector.h
  lldb/source/Plugins/Process/Linux/IntelPTMultiCoreTrace.cpp
  lldb/source/Plugins/Process/Linux/IntelPTMultiCoreTrace.h
  lldb/source/Plugins/Process/Linux/IntelPTSingleBufferTrace.cpp
  lldb/source/Plugins/Process/Linux/IntelPTSingleBufferTrace.h
  lldb/source/Plugins/Process/Linux/NativeProcessLinux.cpp
  lldb/source/Plugins/Process/Linux/Perf.cpp
  lldb/source/Plugins/Process/Linux/Perf.h
  lldb/source/Plugins/Process/Linux/Procfs.cpp
  lldb/source/Plugins/Process/Linux/Procfs.h
  lldb/source/Plugins/Trace/intel-pt/TraceIntelPT.cpp
  lldb/source/Plugins/Trace/intel-pt/TraceIntelPTOptions.td
  lldb/source/Target/Trace.cpp
  lldb/source/Utility/TraceGDBRemotePackets.cpp
  lldb/source/Utility/TraceIntelPTGDBRemotePackets.cpp
  
lldb/test/API/commands/trace/multiple-threads/TestTraceStartStopMultipleThreads.py
  lldb/unittests/Process/Linux/ProcfsTests.cpp

Index: lldb/unittests/Process/Linux/ProcfsTests.cpp
===
--- lldb/unittests/Process/Linux/ProcfsTests.cpp
+++ lldb/unittests/Process/Linux/ProcfsTests.cpp
@@ -18,7 +18,7 @@
 using namespace llvm;
 
 TEST(Perf, HardcodedLogicalCoreIDs) {
-  Expected> core_ids =
+  Expected> core_ids =
   GetAvailableLogicalCoreIDs(R"(processor   : 13
 vendor_id   : GenuineIntel
 cpu family  : 6
@@ -98,7 +98,7 @@
 GTEST_SKIP() << toString(buffer_or_error.takeError());
 
   // At this point we shouldn't fail parsing the core ids
-  Expected> core_ids = GetAvailableLogicalCoreIDs();
+  Expected> core_ids = GetAvailableLogicalCoreIDs();
   ASSERT_TRUE((bool)core_ids);
   ASSERT_GT((int)core_ids->size(), 0) << "We must see at least one core";
 }
Index: lldb/test/API/commands/trace/multiple-threads/TestTraceStartStopMultipleThreads.py
===
--- lldb/test/API/commands/trace/multiple-threads/TestTraceStartStopMultipleThreads.py
+++ lldb/test/API/commands/trace/multiple-threads/TestTraceStartStopMultipleThreads.py
@@ -30,6 +30,8 @@
 self.expect("continue")
 self.expect("thread trace dump instructions", substrs=['main.cpp:4'])
 
+self.traceStopProcess()
+
 @skipIf(oslist=no_match(['linux']), archs=no_match(['i386', 'x86_64']))
 @testSBAPIAndCommands
 def testStartMultipleLiveThreadsWithStops(self):
@@ -65,6 +67,8 @@
 
 self.expect("thread trace dump instructions 2", substrs=['not traced'])
 
+self.traceStopProcess()
+
 @skipIf(oslist=no_match(['linux']), archs=no_match(['i386', 'x86_64']))
 @testSBAPIAndCommands
 def testStartMultipleLiveThreadsWithStops(self):
@@ -100,6 +104,8 @@
 self.expect("thread trace dump instructions 1", substrs=['not traced'])
 self.expect("thread trace dump instructions 2", substrs=['not traced'])
 
+self.traceStopProcess()
+
 @skipIf(oslist=no_match(['linux']), archs=no_match(['i386', 'x86_64']))
 def testStartMultipleLiveThreadsWithThreadStartAll(self):
 self.build()
@@ -156,6 +162,8 @@
 @skipIf(oslist=no_match(['linux']), archs=no_match(['i386', 'x86_64']))
 @testSBAPIAndCommands
 def testStartPerCoreSession(self):
+self.skipIfPerCoreTracingIsNotSupported()
+
 self.build()
 exe = self.getBuildArtifact("a.out")
 self.dbg.CreateTarget(exe)
@@ -163,6 +171,32 @@
 self.expect("b main")
 self.expect("r")
 
-self.traceStartProcess(
-error=True, perCoreTracing=True,
-substrs=["Per-core tracing is not supported"])
+# We should fail if we hit the total buffer limit. Useful if the number
+# of cores is huge.
+self.traceStartProcess(error="True", processBufferSizeLimit=100,
+perCoreTracing=True,
+substrs=["The process can't be traced because the process trace size "
+"limit has been reached. Consider retracing with a higher limit."])
+
+self.traceStartProcess(perCoreTracing=True)
+self.traceStopProcess()
+
+self.traceStartProcess(perCoreTracing=True)
+# We can't supp

[Lldb-commits] [PATCH] D125325: Pass plugin_name in SBProcess::SaveCore

2022-05-11 Thread Jim Ingham via Phabricator via lldb-commits 
jingham added a comment.

In D125325#3505305 , @PatriosTheGreat 
wrote:

> Hi Greg.
>
> Thanks for the review.
> I fixed the feedback.
> I forgot the default initialization of plugin_name parameter in SBProcess.i 
> in previous version, but I assume it's still better to explicitly create a 
> separate method.

Yes, a method with a default parameter has a different mangled name from the 
method w/o the parameter, so it's still a binary incompatible change.


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

https://reviews.llvm.org/D125325

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

[Lldb-commits] [PATCH] D124962: [trace][intelpt] Support system-wide tracing [5] - Disable/enable per-core tracing based on the process state

2022-05-11 Thread walter erquinigo via Phabricator via lldb-commits 
wallace added inline comments.



Comment at: lldb/source/Plugins/Process/Linux/IntelPTSingleBufferTrace.cpp:234
+IntelPTSingleBufferTrace::GetTraceBuffer(size_t offset, size_t size,
+ bool flush) {
   std::vector data(size, 0);

jj10306 wrote:
> What's the purpose of this new `flush` flag? When would you want to call this 
> method with it set to false? I can only think of cases when you want to flush 
> the buffer if you're trying to read its data
This is nonsense, I shouldn't have created this flag =P



Comment at: lldb/source/Plugins/Process/Linux/Perf.h:216-222
+  llvm::Error DisableWithIoctl() const;
+
+  /// Use the ioctl API to enable the perf event.
+  ///
+  /// \return
+  ///   An Error if the perf event couldn't be enabled.
+  llvm::Error EnableWithIoctl() const;

jj10306 wrote:
> Nice, happy to see we are extending the mini perf API (:
> In the future we also can update this to control whether or not the event is 
> enabled at perf_event_open time because that's the default but there may be 
> cases where you don't want the event to be enabled until you explicitly 
> enable it w ioctl
that's a good idea. I think I'll do it now


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D124962

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

[Lldb-commits] [PATCH] D124962: [trace][intelpt] Support system-wide tracing [5] - Disable/enable per-core tracing based on the process state

2022-05-11 Thread walter erquinigo via Phabricator via lldb-commits 
wallace updated this revision to Diff 428695.
wallace added a comment.

- remove the flush parameter
- use perf_event_attr.disabled to set the initial state of the collection


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D124962

Files:
  lldb/include/lldb/Host/common/NativeProcessProtocol.h
  lldb/source/Host/common/NativeProcessProtocol.cpp
  lldb/source/Plugins/Process/Linux/IntelPTCollector.cpp
  lldb/source/Plugins/Process/Linux/IntelPTCollector.h
  lldb/source/Plugins/Process/Linux/IntelPTMultiCoreTrace.cpp
  lldb/source/Plugins/Process/Linux/IntelPTMultiCoreTrace.h
  lldb/source/Plugins/Process/Linux/IntelPTSingleBufferTrace.cpp
  lldb/source/Plugins/Process/Linux/IntelPTSingleBufferTrace.h
  lldb/source/Plugins/Process/Linux/NativeProcessLinux.cpp
  lldb/source/Plugins/Process/Linux/NativeProcessLinux.h
  lldb/source/Plugins/Process/Linux/Perf.cpp
  lldb/source/Plugins/Process/Linux/Perf.h

Index: lldb/source/Plugins/Process/Linux/Perf.h
===
--- lldb/source/Plugins/Process/Linux/Perf.h
+++ lldb/source/Plugins/Process/Linux/Perf.h
@@ -213,6 +213,19 @@
   ///   \a ArrayRef extending \a aux_size bytes from \a aux_offset.
   llvm::ArrayRef GetAuxBuffer() const;
 
+  /// Use the ioctl API to disable the perf event. This doesn't terminate the
+  /// perf event.
+  ///
+  /// \return
+  ///   An Error if the perf event couldn't be disabled.
+  llvm::Error DisableWithIoctl() const;
+
+  /// Use the ioctl API to enable the perf event.
+  ///
+  /// \return
+  ///   An Error if the perf event couldn't be enabled.
+  llvm::Error EnableWithIoctl() const;
+
 private:
   /// Create new \a PerfEvent.
   ///
Index: lldb/source/Plugins/Process/Linux/Perf.cpp
===
--- lldb/source/Plugins/Process/Linux/Perf.cpp
+++ lldb/source/Plugins/Process/Linux/Perf.cpp
@@ -15,6 +15,7 @@
 #include "llvm/Support/MathExtras.h"
 #include "llvm/Support/MemoryBuffer.h"
 
+#include 
 #include 
 #include 
 #include 
@@ -219,3 +220,19 @@
   return {reinterpret_cast(m_aux_base.get()),
static_cast(mmap_metadata.aux_size)};
 }
+
+Error PerfEvent::DisableWithIoctl() const {
+  if (ioctl(*m_fd, PERF_EVENT_IOC_DISABLE) < 0)
+return createStringError(inconvertibleErrorCode(),
+ "Can't disable perf event. %s",
+ std::strerror(errno));
+  return Error::success();
+}
+
+Error PerfEvent::EnableWithIoctl() const {
+  if (ioctl(*m_fd, PERF_EVENT_IOC_ENABLE) < 0)
+return createStringError(inconvertibleErrorCode(),
+ "Can't disable perf event. %s",
+ std::strerror(errno));
+  return Error::success();
+}
Index: lldb/source/Plugins/Process/Linux/NativeProcessLinux.h
===
--- lldb/source/Plugins/Process/Linux/NativeProcessLinux.h
+++ lldb/source/Plugins/Process/Linux/NativeProcessLinux.h
@@ -209,6 +209,8 @@
   /// stopping for threads being destroyed.
   Status NotifyTracersOfThreadDestroyed(lldb::tid_t tid);
 
+  void NotifyTracersProcessStateChanged(lldb::StateType state) override;
+
   /// Writes the raw event message code (vis-a-vis PTRACE_GETEVENTMSG)
   /// corresponding to the given thread ID to the memory pointed to by @p
   /// message.
Index: lldb/source/Plugins/Process/Linux/NativeProcessLinux.cpp
===
--- lldb/source/Plugins/Process/Linux/NativeProcessLinux.cpp
+++ lldb/source/Plugins/Process/Linux/NativeProcessLinux.cpp
@@ -1665,6 +1665,11 @@
   SignalIfAllThreadsStopped();
 }
 
+void NativeProcessLinux::NotifyTracersProcessStateChanged(
+lldb::StateType state) {
+  m_intel_pt_collector.OnProcessStateChanged(state);
+}
+
 Status NativeProcessLinux::NotifyTracersOfNewThread(lldb::tid_t tid) {
   Log *log = GetLog(POSIXLog::Thread);
   Status error(m_intel_pt_collector.OnThreadCreated(tid));
Index: lldb/source/Plugins/Process/Linux/IntelPTSingleBufferTrace.h
===
--- lldb/source/Plugins/Process/Linux/IntelPTSingleBufferTrace.h
+++ lldb/source/Plugins/Process/Linux/IntelPTSingleBufferTrace.h
@@ -27,6 +27,11 @@
 
 using IntelPTSingleBufferTraceUP = std::unique_ptr;
 
+enum class TraceCollectionState {
+  Running,
+  Paused,
+};
+
 /// This class wraps a single perf event collecting intel pt data in a single
 /// buffer.
 class IntelPTSingleBufferTrace {
@@ -43,13 +48,17 @@
   /// \param[in] core_id
   /// The CPU core id where to trace. If \b None, then this traces all CPUs.
   ///
+  /// \param[in] initial_state
+  /// The initial trace collection state.
+  ///
   /// \return
   ///   A \a IntelPTSingleBufferTrace instance if tracing was successful, or
   ///   an \a llvm::Error otherwise.
   static llvm::Exp

[Lldb-commits] [PATCH] D125047: [trace][intelpt] Support system-wide tracing [6] - Break IntelPTCollector into smaller files and minor refactor

2022-05-11 Thread walter erquinigo via Phabricator via lldb-commits 
wallace added inline comments.



Comment at: lldb/source/Utility/TraceGDBRemotePackets.cpp:136
 {"tid", packet.tid},
-{"size", packet.size}});
+{"size", static_cast(packet.size)}});
 }

jj10306 wrote:
> why is this needed now? I thought that unsigned ints were now supported by 
> the json lib. 
> is this temporary because of the bug you address in D125322?
i just need to rebase :)


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D125047

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

[Lldb-commits] [PATCH] D125047: [trace][intelpt] Support system-wide tracing [6] - Break IntelPTCollector into smaller files and minor refactor

2022-05-11 Thread walter erquinigo via Phabricator via lldb-commits 
wallace updated this revision to Diff 428701.
wallace added a comment.

rebase


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D125047

Files:
  lldb/include/lldb/Utility/TraceGDBRemotePackets.h
  lldb/source/Plugins/Process/Linux/CMakeLists.txt
  lldb/source/Plugins/Process/Linux/IntelPTCollector.cpp
  lldb/source/Plugins/Process/Linux/IntelPTCollector.h
  lldb/source/Plugins/Process/Linux/IntelPTPerThreadProcessTrace.cpp
  lldb/source/Plugins/Process/Linux/IntelPTPerThreadProcessTrace.h
  lldb/source/Plugins/Process/Linux/IntelPTThreadTraceCollection.cpp
  lldb/source/Plugins/Process/Linux/IntelPTThreadTraceCollection.h

Index: lldb/source/Plugins/Process/Linux/IntelPTThreadTraceCollection.h
===
--- /dev/null
+++ lldb/source/Plugins/Process/Linux/IntelPTThreadTraceCollection.h
@@ -0,0 +1,71 @@
+//===-- IntelPTThreadTraceCollection.h  -*- C++ -*-===//
+//
+// Part of the LLVM Project, under the Apache License v2.0 with LLVM Exceptions.
+// See https://llvm.org/LICENSE.txt for license information.
+// SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception
+//
+//===--===//
+
+#ifndef liblldb_IntelPTPerThreadTraceCollection_H_
+#define liblldb_IntelPTPerThreadTraceCollection_H_
+
+#include "IntelPTSingleBufferTrace.h"
+
+namespace lldb_private {
+namespace process_linux {
+
+/// Manages a list of thread traces.
+class IntelPTThreadTraceCollection {
+public:
+  IntelPTThreadTraceCollection() {}
+
+  /// Dispose of all traces
+  void Clear();
+
+  /// \return
+  ///   \b true if and only if this instance of tracing the provided \p tid.
+  bool TracesThread(lldb::tid_t tid) const;
+
+  /// \return
+  ///   The total sum of the trace buffer sizes used by this collection.
+  size_t GetTotalBufferSize() const;
+
+  /// Execute the provided callback on each thread that is being traced.
+  ///
+  /// \param[in] callback.tid
+  ///   The id of the thread that is being traced.
+  ///
+  /// \param[in] callback.core_trace
+  ///   The single-buffer trace instance for the given core.
+  void ForEachThread(std::function
+ callback);
+
+  llvm::Expected GetTracedThread(lldb::tid_t tid);
+
+  /// Start tracing the thread given by its \p tid.
+  ///
+  /// \return
+  ///   An error if the operation failed.
+  llvm::Error TraceStart(lldb::tid_t tid,
+ const TraceIntelPTStartRequest &request);
+
+  /// Stop tracing the thread given by its \p tid.
+  ///
+  /// \return
+  ///   An error if the given thread is not being traced or tracing couldn't be
+  ///   stopped.
+  llvm::Error TraceStop(lldb::tid_t tid);
+
+  size_t GetTracedThreadsCount() const;
+
+private:
+  llvm::DenseMap m_thread_traces;
+  /// Total actual thread buffer size in bytes
+  size_t m_total_buffer_size = 0;
+};
+
+} // namespace process_linux
+} // namespace lldb_private
+
+#endif // liblldb_IntelPTPerThreadTraceCollection_H_
Index: lldb/source/Plugins/Process/Linux/IntelPTThreadTraceCollection.cpp
===
--- /dev/null
+++ lldb/source/Plugins/Process/Linux/IntelPTThreadTraceCollection.cpp
@@ -0,0 +1,74 @@
+//===-- IntelPTThreadTraceCollection.cpp --===//
+//
+// Part of the LLVM Project, under the Apache License v2.0 with LLVM Exceptions.
+// See https://llvm.org/LICENSE.txt for license information.
+// SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception
+//
+//===--===//
+
+#include "IntelPTThreadTraceCollection.h"
+
+using namespace lldb;
+using namespace lldb_private;
+using namespace process_linux;
+using namespace llvm;
+
+bool IntelPTThreadTraceCollection::TracesThread(lldb::tid_t tid) const {
+  return m_thread_traces.count(tid);
+}
+
+Error IntelPTThreadTraceCollection::TraceStop(lldb::tid_t tid) {
+  auto it = m_thread_traces.find(tid);
+  if (it == m_thread_traces.end())
+return createStringError(inconvertibleErrorCode(),
+ "Thread %" PRIu64 " not currently traced", tid);
+  m_total_buffer_size -= it->second->GetTraceBufferSize();
+  m_thread_traces.erase(tid);
+  return Error::success();
+}
+
+Error IntelPTThreadTraceCollection::TraceStart(
+lldb::tid_t tid, const TraceIntelPTStartRequest &request) {
+  if (TracesThread(tid))
+return createStringError(inconvertibleErrorCode(),
+ "Thread %" PRIu64 " already traced", tid);
+
+  Expected trace_up =
+  IntelPTSingleBufferTrace::Start(request, tid, /*core_id=*/None,
+  TraceCollectionState::Running);
+  if (!trace_up)
+return trace_up.takeError();
+
+  m_total_buffer_size += (*trace_up)->GetTraceBufferSize();
+  m_thread_traces.try_emplace(tid

[Lldb-commits] [PATCH] D125325: Pass plugin_name in SBProcess::SaveCore

2022-05-11 Thread Greg Clayton via Phabricator via lldb-commits 
clayborg added inline comments.



Comment at: lldb/include/lldb/API/SBProcess.h:340
 
   /// Save the state of the process in a core file (or mini dump on Windows).
+  lldb::SBError SaveCore(const char *file_name, const char *plugin_name);

I would modify the header doc to be a bit more descriptive. Also, the user 
doesn't need to know about the plug-in name, we should call it something else 
like maybe "flavor"? Right now we can save "mach-o" (from ObjectFileMachO) or 
"minidump" (from ObjectFileMinidump. We don't have ELF core file support yet in 
ObjectFileELF. So the users should be able to pick from a list. 



Comment at: lldb/include/lldb/API/SBProcess.h:341
   /// Save the state of the process in a core file (or mini dump on Windows).
+  lldb::SBError SaveCore(const char *file_name, const char *plugin_name);
+





Comment at: lldb/include/lldb/API/SBProcess.h:343
+
+  // Save the state of the process with the default plugin.
   lldb::SBError SaveCore(const char *file_name);




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

https://reviews.llvm.org/D125325

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

[Lldb-commits] [PATCH] D125347: Add "indexedVariables" to variables with lots of children.

2022-05-11 Thread Greg Clayton via Phabricator via lldb-commits 
clayborg updated this revision to Diff 428789.
clayborg added a comment.

Remove logging change from VSCode.cpp that was accidentally left in.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D125347

Files:
  lldb/test/API/tools/lldb-vscode/variables/TestVSCode_variables.py
  lldb/test/API/tools/lldb-vscode/variables/main.cpp
  lldb/tools/lldb-vscode/JSONUtils.cpp

Index: lldb/tools/lldb-vscode/JSONUtils.cpp
===
--- lldb/tools/lldb-vscode/JSONUtils.cpp
+++ lldb/tools/lldb-vscode/JSONUtils.cpp
@@ -9,6 +9,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include "llvm/ADT/Optional.h"
 #include "llvm/Support/FormatAdapters.h"
@@ -1024,7 +1025,37 @@
   if (format_hex)
 v.SetFormat(lldb::eFormatHex);
   SetValueForKey(v, object, "value");
-  auto type_cstr = v.GetType().GetDisplayTypeName();
+  auto type_obj = v.GetType();
+  auto type_cstr = type_obj.GetDisplayTypeName();
+  // If we have a type with many many children, we would like to be able to
+  // give a hint to the IDE that the type has indexed children so that the
+  // request can be broken up in grabbing only a few children at a time. We want
+  // to be careful and only call "v.GetNumChildren()" if we have an array type
+  // or if we have a synthetic child provider. We don't want to call
+  // "v.GetNumChildren()" on all objects as class, struct and union types don't
+  // need to be completed if they are never expanded. So we want to avoid
+  // calling this to only cases where we it makes sense to keep performance high
+  // during normal debugging.
+
+  // If we have an array type, say that it is indexed and provide the number of
+  // children in case we have a huge array. If we don't do this, then we might
+  // take a while to produce all children at onces which can delay your debug
+  // session.
+  const bool is_array = type_obj.IsArrayType();
+  const bool is_synthetic = v.IsSynthetic();
+  if (is_array || is_synthetic) {
+const auto num_children = v.GetNumChildren();
+if (is_array) {
+  object.try_emplace("indexedVariables", num_children);
+} else {
+  // If a type has a synthetic child provider, then the SBType of "v" won't
+  // tell us anything about what might be displayed. So we can check if the
+  // first child's name is "[0]" and then we can say it is indexed.
+  const char *first_child_name = v.GetChildAtIndex(0).GetName();
+  if (first_child_name && strcmp(first_child_name, "[0]") == 0)
+object.try_emplace("indexedVariables", num_children);
+}
+  }
   EmplaceSafeString(object, "type", type_cstr ? type_cstr : NO_TYPENAME);
   if (varID != INT64_MAX)
 object.try_emplace("id", varID);
Index: lldb/test/API/tools/lldb-vscode/variables/main.cpp
===
--- lldb/test/API/tools/lldb-vscode/variables/main.cpp
+++ lldb/test/API/tools/lldb-vscode/variables/main.cpp
@@ -5,10 +5,10 @@
   int y;
   int buffer[BUFFER_SIZE];
 };
-
+#include 
 int g_global = 123;
 static int s_global = 234;
-
+int test_indexedVariables();
 int main(int argc, char const *argv[]) {
   static float s_local = 2.25;
   PointType pt = { 11,22, {0}};
@@ -22,5 +22,15 @@
   s_global = x; // breakpoint 2
 }
   }
-  return 0; // breakpoint 3
+  return test_indexedVariables(); // breakpoint 3
+}
+
+int test_indexedVariables() {
+  int small_array[5] = {1, 2, 3, 4, 5};
+  int large_array[200];
+  std::vector small_vector;
+  std::vector large_vector;
+  small_vector.assign(5, 0);
+  large_vector.assign(200, 0);
+  return 0; // breakpoint 4
 }
Index: lldb/test/API/tools/lldb-vscode/variables/TestVSCode_variables.py
===
--- lldb/test/API/tools/lldb-vscode/variables/TestVSCode_variables.py
+++ lldb/test/API/tools/lldb-vscode/variables/TestVSCode_variables.py
@@ -30,8 +30,8 @@
 verify_value = verify[key]
 actual_value = actual[key]
 self.assertEqual(verify_value, actual_value,
-'"%s" keys don\'t match (%s != %s)' % (
-key, actual_value, verify_value))
+'"%s" keys don\'t match (%s != %s) from:\n%s' % (
+key, actual_value, verify_value, actual))
 if 'startswith' in verify_dict:
 verify = verify_dict['startswith']
 for key in verify:
@@ -43,6 +43,11 @@
  ' "%s")') % (
 key, actual_value,
 verify_value))
+if 'missing' in verify_dict:
+missing = verify_dict['missing']
+for key in missing:
+self.assertTrue(key not in actual,
+'key "%s" is not expected in %s'

[Lldb-commits] [PATCH] D125347: Add "indexedVariables" to variables with lots of children.

2022-05-11 Thread Greg Clayton via Phabricator via lldb-commits 
clayborg added inline comments.



Comment at: lldb/tools/lldb-vscode/JSONUtils.cpp:1055
+  const char *first_child_name = v.GetChildAtIndex(0).GetName();
+  if (first_child_name && strcmp(first_child_name, "[0]") == 0)
+object.try_emplace("indexedVariables", num_children);

All of the collection classes emit very similar stuff with indexed names. 

```
std::unordered_map u = {
{"RED","#FF"},
{"GREEN","#00FF00"},
{"BLUE","#FF"}
};
```
Then when we debug:
```
(std::unordered_map, 
std::allocator >, std::basic_string, 
std::allocator >, std::hash, std::allocator > >, 
std::equal_to, 
std::allocator > >, std::allocator, std::allocator >, 
std::basic_string, std::allocator > > > >) u 
= size=3 {
  [0] = {
__cc = (first = "BLUE", second = "#FF")
  }
  [1] = {
__cc = (first = "GREEN", second = "#00FF00")
  }
  [2] = {
__cc = (first = "RED", second = "#FF")
  }
}
```
So it will work for unordered_map.



Comment at: lldb/tools/lldb-vscode/JSONUtils.cpp:1035
+  // or if we have a synthetic child provider. We don't want to call
+  // "v.GetNumChildren()" on all objects as class, struct and union types don't
+  // need to be completed if they are never expanded. So we want to avoid

yinghuitan wrote:
> It sucks that `indexedVariables` has be to be filled at container variable 
> creation time to determine the children number. 
> A better DAP design would be VSCode asking for children count at container 
> expansion time. Then we can always call `GetNumChildren()` since all children 
> will be enumerated anyway.
Agreed, but not much we can do there.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D125347

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

[Lldb-commits] [lldb] 91d5bfd - Add "indexedVariables" to variables with lots of children.

2022-05-11 Thread Greg Clayton via lldb-commits 

Author: Greg Clayton
Date: 2022-05-11T16:17:57-07:00
New Revision: 91d5bfdb7996b353097c886128fc984e310f7122

URL: 
https://github.com/llvm/llvm-project/commit/91d5bfdb7996b353097c886128fc984e310f7122
DIFF: 
https://github.com/llvm/llvm-project/commit/91d5bfdb7996b353097c886128fc984e310f7122.diff

LOG: Add "indexedVariables" to variables with lots of children.

Prior to this fix if we have a really large array or collection class, we would 
end up always creating all of the child variables for an array or collection 
class. If the number of children was very high this can cause delays when 
expanding variables. By adding the "indexedVariables" to variables with lots of 
children, we can keep good performance in the variables view at all times. This 
patch will add the "indexedVariables" key/value pair to any "Variable" JSON 
dictionairies when we have an array of synthetic child provider that will 
create more than 100 children.

We have to be careful to not call "uint32_t SBValue::GetNumChildren()" on any 
lldb::SBValue that we use because it can cause a class, struct or union to 
complete the type in order to be able to properly tell us how many children it 
has and this can be expensive if you have a lot of variables. By default LLDB 
won't need to complete a type if we have variables that are classes, structs or 
unions unless the user expands the variable in the variable view. So we try to 
only get the GetNumChildren() when we have an array, as this is a cheap 
operation, or a synthetic child provider, most of which are for showing 
collections that typically fall into this category. We add a variable 
reference, which indicates that something can be expanded, when the function 
"bool SBValue::MightHaveChildren()" is true as this call doesn't need to 
complete the type in order to return true. This way if no one ever expands 
class variables, we don't need to complete the type.

Differential Revision: https://reviews.llvm.org/D125347

Added: 


Modified: 
lldb/test/API/tools/lldb-vscode/variables/TestVSCode_variables.py
lldb/test/API/tools/lldb-vscode/variables/main.cpp
lldb/tools/lldb-vscode/JSONUtils.cpp

Removed: 




diff  --git a/lldb/test/API/tools/lldb-vscode/variables/TestVSCode_variables.py 
b/lldb/test/API/tools/lldb-vscode/variables/TestVSCode_variables.py
index 9a4a5de40e718..2a473df67c78a 100644
--- a/lldb/test/API/tools/lldb-vscode/variables/TestVSCode_variables.py
+++ b/lldb/test/API/tools/lldb-vscode/variables/TestVSCode_variables.py
@@ -30,8 +30,8 @@ def verify_values(self, verify_dict, actual, 
varref_dict=None, expression=None):
 verify_value = verify[key]
 actual_value = actual[key]
 self.assertEqual(verify_value, actual_value,
-'"%s" keys don\'t match (%s != %s)' % (
-key, actual_value, verify_value))
+'"%s" keys don\'t match (%s != %s) from:\n%s' 
% (
+key, actual_value, verify_value, actual))
 if 'startswith' in verify_dict:
 verify = verify_dict['startswith']
 for key in verify:
@@ -43,6 +43,11 @@ def verify_values(self, verify_dict, actual, 
varref_dict=None, expression=None):
  ' "%s")') % (
 key, actual_value,
 verify_value))
+if 'missing' in verify_dict:
+missing = verify_dict['missing']
+for key in missing:
+self.assertTrue(key not in actual,
+'key "%s" is not expected in %s' % (key, 
actual))
 hasVariablesReference = 'variablesReference' in actual
 varRef = None
 if hasVariablesReference:
@@ -310,22 +315,39 @@ def test_scopes_and_evaluate_expansion(self):
 locals = self.vscode.get_local_variables()
 buffer_children = make_buffer_verify_dict(0, 32)
 verify_locals = {
-"argc": {"equals": {"type": "int", "value": "1"}},
+"argc": {
+"equals": {"type": "int", "value": "1"},
+"missing": ["indexedVariables"],
+},
 "argv": {
 "equals": {"type": "const char **"},
 "startswith": {"value": "0x"},
 "hasVariablesReference": True,
+"missing": ["indexedVariables"],
 },
 "pt": {
 "equals": {"type": "PointType"},
 "hasVariablesReference": True,
+"missing": ["indexedVariables"],
 "children": {
-"x": {"equals": {"type": "int", "value": "11"}},
-"y": {"equals": {"type": "int", "value": "22"}},
-"buffer": {"children": buffer_children},
+"x": {
+

[Lldb-commits] [PATCH] D125347: Add "indexedVariables" to variables with lots of children.

2022-05-11 Thread Greg Clayton via Phabricator via lldb-commits 
This revision was automatically updated to reflect the committed changes.
Closed by commit rG91d5bfdb7996: Add "indexedVariables" to variables 
with lots of children. (authored by clayborg).

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D125347

Files:
  lldb/test/API/tools/lldb-vscode/variables/TestVSCode_variables.py
  lldb/test/API/tools/lldb-vscode/variables/main.cpp
  lldb/tools/lldb-vscode/JSONUtils.cpp

Index: lldb/tools/lldb-vscode/JSONUtils.cpp
===
--- lldb/tools/lldb-vscode/JSONUtils.cpp
+++ lldb/tools/lldb-vscode/JSONUtils.cpp
@@ -9,6 +9,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include "llvm/ADT/Optional.h"
 #include "llvm/Support/FormatAdapters.h"
@@ -1024,7 +1025,37 @@
   if (format_hex)
 v.SetFormat(lldb::eFormatHex);
   SetValueForKey(v, object, "value");
-  auto type_cstr = v.GetType().GetDisplayTypeName();
+  auto type_obj = v.GetType();
+  auto type_cstr = type_obj.GetDisplayTypeName();
+  // If we have a type with many many children, we would like to be able to
+  // give a hint to the IDE that the type has indexed children so that the
+  // request can be broken up in grabbing only a few children at a time. We want
+  // to be careful and only call "v.GetNumChildren()" if we have an array type
+  // or if we have a synthetic child provider. We don't want to call
+  // "v.GetNumChildren()" on all objects as class, struct and union types don't
+  // need to be completed if they are never expanded. So we want to avoid
+  // calling this to only cases where we it makes sense to keep performance high
+  // during normal debugging.
+
+  // If we have an array type, say that it is indexed and provide the number of
+  // children in case we have a huge array. If we don't do this, then we might
+  // take a while to produce all children at onces which can delay your debug
+  // session.
+  const bool is_array = type_obj.IsArrayType();
+  const bool is_synthetic = v.IsSynthetic();
+  if (is_array || is_synthetic) {
+const auto num_children = v.GetNumChildren();
+if (is_array) {
+  object.try_emplace("indexedVariables", num_children);
+} else {
+  // If a type has a synthetic child provider, then the SBType of "v" won't
+  // tell us anything about what might be displayed. So we can check if the
+  // first child's name is "[0]" and then we can say it is indexed.
+  const char *first_child_name = v.GetChildAtIndex(0).GetName();
+  if (first_child_name && strcmp(first_child_name, "[0]") == 0)
+object.try_emplace("indexedVariables", num_children);
+}
+  }
   EmplaceSafeString(object, "type", type_cstr ? type_cstr : NO_TYPENAME);
   if (varID != INT64_MAX)
 object.try_emplace("id", varID);
Index: lldb/test/API/tools/lldb-vscode/variables/main.cpp
===
--- lldb/test/API/tools/lldb-vscode/variables/main.cpp
+++ lldb/test/API/tools/lldb-vscode/variables/main.cpp
@@ -5,10 +5,10 @@
   int y;
   int buffer[BUFFER_SIZE];
 };
-
+#include 
 int g_global = 123;
 static int s_global = 234;
-
+int test_indexedVariables();
 int main(int argc, char const *argv[]) {
   static float s_local = 2.25;
   PointType pt = { 11,22, {0}};
@@ -22,5 +22,15 @@
   s_global = x; // breakpoint 2
 }
   }
-  return 0; // breakpoint 3
+  return test_indexedVariables(); // breakpoint 3
+}
+
+int test_indexedVariables() {
+  int small_array[5] = {1, 2, 3, 4, 5};
+  int large_array[200];
+  std::vector small_vector;
+  std::vector large_vector;
+  small_vector.assign(5, 0);
+  large_vector.assign(200, 0);
+  return 0; // breakpoint 4
 }
Index: lldb/test/API/tools/lldb-vscode/variables/TestVSCode_variables.py
===
--- lldb/test/API/tools/lldb-vscode/variables/TestVSCode_variables.py
+++ lldb/test/API/tools/lldb-vscode/variables/TestVSCode_variables.py
@@ -30,8 +30,8 @@
 verify_value = verify[key]
 actual_value = actual[key]
 self.assertEqual(verify_value, actual_value,
-'"%s" keys don\'t match (%s != %s)' % (
-key, actual_value, verify_value))
+'"%s" keys don\'t match (%s != %s) from:\n%s' % (
+key, actual_value, verify_value, actual))
 if 'startswith' in verify_dict:
 verify = verify_dict['startswith']
 for key in verify:
@@ -43,6 +43,11 @@
  ' "%s")') % (
 key, actual_value,
 verify_value))
+if 'missing' in verify_dict:
+missing = verify_dict['missing']
+for key in missing:
+self.assertTrue(key not in actual,
+

[Lldb-commits] [PATCH] D125434: Make a more convenient way to allow Darwin users to ignore certain Mach Exceptions

2022-05-11 Thread Jim Ingham via Phabricator via lldb-commits 
jingham created this revision.
jingham added reviewers: JDevlieghere, jasonmolenda, labath.
Herald added a project: All.
jingham requested review of this revision.
Herald added a project: LLDB.
Herald added a subscriber: lldb-commits.

For relatively uninteresting reasons, it is not possible when running under the 
debugger to invoke the mechanism that converts a Mach Exception into its BSD 
signal equivalent.  The Mach Exceptions contain more information than the 
signal does, so we prefer to stop at the mach exception raise for most 
purposes.  But if your application relies on a SIGBUS, SIGSEGV, etc. handler, 
then your application won't run properly in the debugger, it will just get 
stuck on the exception.

The was a workaround for this added a while back - by passing -U to the 
debugger, EXC_BAD_ACCESS, EXC_BAD_INSTRUCTION and EXC_ARITHMETIC are masked 
out.  But this isn't terribly convenient, because you have to invoke 
debugserver specially so you have to do this every time you debug, you can't 
use the feature when you don't control how debugserver is launched, and you 
can't control which exception you want to mask out.

I made this more convenient by adding a QSetIgnoredExceptions packet to 
debugserver which will set the exceptions not to include, so we can direct this 
from lldb.

Then I added a way for Platform to provide "extra startup commands" to the 
remote startup sequence - there was already a way for the user to supply extra 
startup commands, and I could have had users set the QSetIgnoredExceptions in 
the "target.extra-startup-commands", but that would be pretty undiscoverable.  
Instead, I added a "platform.plugin.darwin.ignored-exceptions" property that 
users can set with just the exception mask.  Then PlatformDarwin gathers the 
results of this setting, and conses up the appropriate packet and returns that 
from PlatformDarwin::ExtraStartupCommands.

I also wanted to add a validator for the property.  Since I don't control the 
property creation (that all happens through processing the .td file) I couldn't 
put my validator in the OptionValueString made for the setting on construction, 
so I added an API to set it after the fact.


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D125434

Files:
  lldb/include/lldb/Interpreter/OptionValueString.h
  lldb/include/lldb/Target/Platform.h
  lldb/include/lldb/Utility/StringExtractorGDBRemote.h
  lldb/source/Plugins/Platform/MacOSX/PlatformDarwin.cpp
  lldb/source/Plugins/Platform/MacOSX/PlatformDarwin.h
  lldb/source/Plugins/Platform/MacOSX/PlatformMacOSXProperties.td
  lldb/source/Plugins/Process/gdb-remote/ProcessGDBRemote.cpp
  lldb/source/Target/Platform.cpp
  lldb/source/Utility/StringExtractorGDBRemote.cpp
  lldb/test/API/macosx/ignore_exceptions/Makefile
  lldb/test/API/macosx/ignore_exceptions/TestIgnoredExceptions.py
  lldb/test/API/macosx/ignore_exceptions/main.c
  lldb/tools/debugserver/source/DNB.cpp
  lldb/tools/debugserver/source/DNB.h
  lldb/tools/debugserver/source/MacOSX/MachException.cpp
  lldb/tools/debugserver/source/MacOSX/MachException.h
  lldb/tools/debugserver/source/MacOSX/MachProcess.h
  lldb/tools/debugserver/source/MacOSX/MachProcess.mm
  lldb/tools/debugserver/source/MacOSX/MachTask.h
  lldb/tools/debugserver/source/MacOSX/MachTask.mm
  lldb/tools/debugserver/source/RNBContext.cpp
  lldb/tools/debugserver/source/RNBContext.h
  lldb/tools/debugserver/source/RNBRemote.cpp
  lldb/tools/debugserver/source/RNBRemote.h
  lldb/tools/debugserver/source/debugserver.cpp

Index: lldb/tools/debugserver/source/debugserver.cpp
===
--- lldb/tools/debugserver/source/debugserver.cpp
+++ lldb/tools/debugserver/source/debugserver.cpp
@@ -368,7 +368,7 @@
   DNBLogThreadedIf(LOG_RNB_MINIMAL, "%s Attaching to pid %i...", __FUNCTION__,
attach_pid);
   char err_str[1024];
-  pid = DNBProcessAttach(attach_pid, NULL, ctx.GetUnmaskSignals(), err_str,
+  pid = DNBProcessAttach(attach_pid, NULL, ctx.GetIgnoredExceptions(), err_str,
  sizeof(err_str));
   g_pid = pid;
 
@@ -1275,7 +1275,7 @@
   break;
 
 case 'U':
-  ctx.SetUnmaskSignals(true);
+  ctx.AddDefaultIgnoredExceptions();
   break;
 
 case '2':
@@ -1574,7 +1574,7 @@
 
 RNBLogSTDOUT("Attaching to process %s...\n", attach_pid_name.c_str());
 nub_process_t pid = DNBProcessAttachByName(
-attach_pid_name.c_str(), timeout_ptr, ctx.GetUnmaskSignals(),
+attach_pid_name.c_str(), timeout_ptr, ctx.GetIgnoredExceptions(),
 err_str, sizeof(err_str));
 g_pid = pid;
 if (pid == INVALID_NUB_PROCESS) {
Index: lldb/tools/debugserver/source/RNBRemote.h
===
--- lldb/tools/debugserver/source/RNBRemote.h
+++ lldb/tools/debugserver/source/RNBRemote.h
@@ -110,6 +110,7 @@
 start_noack_mode,  //

[Lldb-commits] [PATCH] D125437: [lldb/API] Add SBCompileUnit::GetIndexForLineEntry method to SB API

2022-05-11 Thread Med Ismail Bennani via Phabricator via lldb-commits 
mib created this revision.
mib added reviewers: jingham, JDevlieghere.
mib added a project: LLDB.
Herald added a subscriber: arphaman.
Herald added a project: All.
mib requested review of this revision.
Herald added a subscriber: lldb-commits.

This patch adds a new `GetIndexForLineEntry` method to the `SBCompileUnit`
class. As the name suggests, given an `SBLineEntry` object, this will
return the line entry index within a specific compile unit.

This method can take a `exact` boolean that will make sure that the
provided line entry matches perfectly another line entry in the compile unit.

rdar://47450887

Signed-off-by: Med Ismail Bennani 


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D125437

Files:
  lldb/bindings/interface/SBCompileUnit.i
  lldb/include/lldb/API/SBCompileUnit.h
  lldb/source/API/SBCompileUnit.cpp


Index: lldb/source/API/SBCompileUnit.cpp
===
--- lldb/source/API/SBCompileUnit.cpp
+++ lldb/source/API/SBCompileUnit.cpp
@@ -77,6 +77,28 @@
   return sb_line_entry;
 }
 
+uint32_t
+SBCompileUnit::GetIndexForLineEntry(const lldb::SBLineEntry &line_entry,
+bool exact) const {
+  LLDB_INSTRUMENT_VA(this, line_entry, exact);
+
+  uint32_t index = UINT32_MAX;
+  if (m_opaque_ptr && line_entry.IsValid()) {
+
+LineEntry found_line_entry;
+
+uint32_t found_index = m_opaque_ptr->FindLineEntry(
+0, line_entry.GetLine(), line_entry.GetFileSpec().get(), exact,
+&found_line_entry);
+
+if (!exact ||
+(exact && !LineEntry::Compare(line_entry.ref(), found_line_entry)))
+  index = found_index;
+  }
+
+  return index;
+}
+
 uint32_t SBCompileUnit::FindLineEntryIndex(uint32_t start_idx, uint32_t line,
SBFileSpec *inline_file_spec) const 
{
   LLDB_INSTRUMENT_VA(this, start_idx, line, inline_file_spec);
Index: lldb/include/lldb/API/SBCompileUnit.h
===
--- lldb/include/lldb/API/SBCompileUnit.h
+++ lldb/include/lldb/API/SBCompileUnit.h
@@ -34,6 +34,9 @@
 
   lldb::SBLineEntry GetLineEntryAtIndex(uint32_t idx) const;
 
+  uint32_t GetIndexForLineEntry(const lldb::SBLineEntry &line_entry,
+bool exact = false) const;
+
   uint32_t FindLineEntryIndex(uint32_t start_idx, uint32_t line,
   lldb::SBFileSpec *inline_file_spec) const;
 
Index: lldb/bindings/interface/SBCompileUnit.i
===
--- lldb/bindings/interface/SBCompileUnit.i
+++ lldb/bindings/interface/SBCompileUnit.i
@@ -67,6 +67,9 @@
 lldb::SBLineEntry
 GetLineEntryAtIndex (uint32_t idx) const;
 
+uint32_t
+GetIndexForLineEntry (const lldb::SBLineEntry &line_entry, bool exact = 
false) const;
+
 uint32_t
 FindLineEntryIndex (uint32_t start_idx,
 uint32_t line,


Index: lldb/source/API/SBCompileUnit.cpp
===
--- lldb/source/API/SBCompileUnit.cpp
+++ lldb/source/API/SBCompileUnit.cpp
@@ -77,6 +77,28 @@
   return sb_line_entry;
 }
 
+uint32_t
+SBCompileUnit::GetIndexForLineEntry(const lldb::SBLineEntry &line_entry,
+bool exact) const {
+  LLDB_INSTRUMENT_VA(this, line_entry, exact);
+
+  uint32_t index = UINT32_MAX;
+  if (m_opaque_ptr && line_entry.IsValid()) {
+
+LineEntry found_line_entry;
+
+uint32_t found_index = m_opaque_ptr->FindLineEntry(
+0, line_entry.GetLine(), line_entry.GetFileSpec().get(), exact,
+&found_line_entry);
+
+if (!exact ||
+(exact && !LineEntry::Compare(line_entry.ref(), found_line_entry)))
+  index = found_index;
+  }
+
+  return index;
+}
+
 uint32_t SBCompileUnit::FindLineEntryIndex(uint32_t start_idx, uint32_t line,
SBFileSpec *inline_file_spec) const {
   LLDB_INSTRUMENT_VA(this, start_idx, line, inline_file_spec);
Index: lldb/include/lldb/API/SBCompileUnit.h
===
--- lldb/include/lldb/API/SBCompileUnit.h
+++ lldb/include/lldb/API/SBCompileUnit.h
@@ -34,6 +34,9 @@
 
   lldb::SBLineEntry GetLineEntryAtIndex(uint32_t idx) const;
 
+  uint32_t GetIndexForLineEntry(const lldb::SBLineEntry &line_entry,
+bool exact = false) const;
+
   uint32_t FindLineEntryIndex(uint32_t start_idx, uint32_t line,
   lldb::SBFileSpec *inline_file_spec) const;
 
Index: lldb/bindings/interface/SBCompileUnit.i
===
--- lldb/bindings/interface/SBCompileUnit.i
+++ lldb/bindings/interface/SBCompileUnit.i
@@ -67,6 +67,9 @@
 lldb::SBLineEntry
 GetLineEntryAtIndex (uint32_t idx) const;
 
+uint32_t
+GetIndexForLineEntry (const lldb::SBLineEntry &line_entry, boo

[Lldb-commits] [PATCH] D125437: [lldb/API] Add SBCompileUnit::GetIndexForLineEntry method to SB API

2022-05-11 Thread Jim Ingham via Phabricator via lldb-commits 
jingham requested changes to this revision.
jingham added a comment.
This revision now requires changes to proceed.

This needs a doctoring for the API and some test.




Comment at: lldb/source/API/SBCompileUnit.cpp:86
+  uint32_t index = UINT32_MAX;
+  if (m_opaque_ptr && line_entry.IsValid()) {
+

llvm would prefer an early return here.



Comment at: lldb/source/API/SBCompileUnit.cpp:94
+
+if (!exact ||
+(exact && !LineEntry::Compare(line_entry.ref(), found_line_entry)))

Why do you have to do this Compare?  You already passed exact to FindLineEntry, 
does FindLineEntry really return line entries that fail your Compare test when 
exact is passed in as true?  That doesn't seem right.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D125437

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

[Lldb-commits] [PATCH] D125437: [lldb/API] Add SBCompileUnit::GetIndexForLineEntry method to SB API

2022-05-11 Thread Med Ismail Bennani via Phabricator via lldb-commits 
mib added inline comments.



Comment at: lldb/source/API/SBCompileUnit.cpp:94
+
+if (!exact ||
+(exact && !LineEntry::Compare(line_entry.ref(), found_line_entry)))

jingham wrote:
> Why do you have to do this Compare?  You already passed exact to 
> FindLineEntry, does FindLineEntry really return line entries that fail your 
> Compare test when exact is passed in as true?  That doesn't seem right.
`exact` could be false, in which case the line entry index returned by 
`FindLineEntry` will be different from the one provided by the user.

But if the user really wants the exact line entry index, we need to compare the 
returned line entry and the one provided by the user.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D125437

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

[Lldb-commits] [PATCH] D125437: [lldb/API] Add SBCompileUnit::GetIndexForLineEntry method to SB API

2022-05-11 Thread Med Ismail Bennani via Phabricator via lldb-commits 
mib updated this revision to Diff 428829.
mib added a comment.

Addressed @jingham comments:

- Use early returns
- Remove `LineEntry::Compare` call since it's already handled by 
`CompileUnit::FindLineEntry`
- Add docstring


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

https://reviews.llvm.org/D125437

Files:
  lldb/bindings/interface/SBCompileUnit.i
  lldb/include/lldb/API/SBCompileUnit.h
  lldb/source/API/SBCompileUnit.cpp


Index: lldb/source/API/SBCompileUnit.cpp
===
--- lldb/source/API/SBCompileUnit.cpp
+++ lldb/source/API/SBCompileUnit.cpp
@@ -77,6 +77,20 @@
   return sb_line_entry;
 }
 
+uint32_t SBCompileUnit::GetIndexForLineEntry(lldb::SBLineEntry &line_entry,
+ bool exact) const {
+  LLDB_INSTRUMENT_VA(this, line_entry, exact);
+
+  if (!m_opaque_ptr || !line_entry.IsValid())
+return UINT32_MAX;
+
+  LineEntry found_line_entry;
+
+  return m_opaque_ptr->FindLineEntry(0, line_entry.GetLine(),
+ line_entry.GetFileSpec().get(), exact,
+ &line_entry.ref());
+}
+
 uint32_t SBCompileUnit::FindLineEntryIndex(uint32_t start_idx, uint32_t line,
SBFileSpec *inline_file_spec) const 
{
   LLDB_INSTRUMENT_VA(this, start_idx, line, inline_file_spec);
Index: lldb/include/lldb/API/SBCompileUnit.h
===
--- lldb/include/lldb/API/SBCompileUnit.h
+++ lldb/include/lldb/API/SBCompileUnit.h
@@ -34,6 +34,9 @@
 
   lldb::SBLineEntry GetLineEntryAtIndex(uint32_t idx) const;
 
+  uint32_t GetIndexForLineEntry(lldb::SBLineEntry &line_entry,
+bool exact = false) const;
+
   uint32_t FindLineEntryIndex(uint32_t start_idx, uint32_t line,
   lldb::SBFileSpec *inline_file_spec) const;
 
Index: lldb/bindings/interface/SBCompileUnit.i
===
--- lldb/bindings/interface/SBCompileUnit.i
+++ lldb/bindings/interface/SBCompileUnit.i
@@ -67,6 +67,22 @@
 lldb::SBLineEntry
 GetLineEntryAtIndex (uint32_t idx) const;
 
+%feature("docstring", "
+ Get the index for a provided line entry in this compile unit.
+
+ @param[in] line_entry
+The SBLineEntry object for which we are looking for the index.
+
+ @param[in] exact
+An optional boolean defaulting to false that ensures that the provided
+line entry has a perfect match in the compile unit.
+
+ @return
+The index of the user-provided line entry. UINT32_MAX if the line entry
+was not found in the compile unit.") GetIndexForLineEntry;
+uint32_t
+GetIndexForLineEntry (lldb::SBLineEntry &line_entry, bool exact = false) 
const;
+
 uint32_t
 FindLineEntryIndex (uint32_t start_idx,
 uint32_t line,


Index: lldb/source/API/SBCompileUnit.cpp
===
--- lldb/source/API/SBCompileUnit.cpp
+++ lldb/source/API/SBCompileUnit.cpp
@@ -77,6 +77,20 @@
   return sb_line_entry;
 }
 
+uint32_t SBCompileUnit::GetIndexForLineEntry(lldb::SBLineEntry &line_entry,
+ bool exact) const {
+  LLDB_INSTRUMENT_VA(this, line_entry, exact);
+
+  if (!m_opaque_ptr || !line_entry.IsValid())
+return UINT32_MAX;
+
+  LineEntry found_line_entry;
+
+  return m_opaque_ptr->FindLineEntry(0, line_entry.GetLine(),
+ line_entry.GetFileSpec().get(), exact,
+ &line_entry.ref());
+}
+
 uint32_t SBCompileUnit::FindLineEntryIndex(uint32_t start_idx, uint32_t line,
SBFileSpec *inline_file_spec) const {
   LLDB_INSTRUMENT_VA(this, start_idx, line, inline_file_spec);
Index: lldb/include/lldb/API/SBCompileUnit.h
===
--- lldb/include/lldb/API/SBCompileUnit.h
+++ lldb/include/lldb/API/SBCompileUnit.h
@@ -34,6 +34,9 @@
 
   lldb::SBLineEntry GetLineEntryAtIndex(uint32_t idx) const;
 
+  uint32_t GetIndexForLineEntry(lldb::SBLineEntry &line_entry,
+bool exact = false) const;
+
   uint32_t FindLineEntryIndex(uint32_t start_idx, uint32_t line,
   lldb::SBFileSpec *inline_file_spec) const;
 
Index: lldb/bindings/interface/SBCompileUnit.i
===
--- lldb/bindings/interface/SBCompileUnit.i
+++ lldb/bindings/interface/SBCompileUnit.i
@@ -67,6 +67,22 @@
 lldb::SBLineEntry
 GetLineEntryAtIndex (uint32_t idx) const;
 
+%feature("docstring", "
+ Get the index for a provided line entry in this compile unit.
+
+ @param[in] line_entry
+The SBLineEntry object for which we are looking for the index.
+
+

[Lldb-commits] [PATCH] D125437: [lldb/API] Add SBCompileUnit::GetIndexForLineEntry method to SB API

2022-05-11 Thread Med Ismail Bennani via Phabricator via lldb-commits 
mib updated this revision to Diff 428841.
mib added a comment.

I forgot to add the test in the previous diffs --'


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

https://reviews.llvm.org/D125437

Files:
  lldb/bindings/interface/SBCompileUnit.i
  lldb/include/lldb/API/SBCompileUnit.h
  lldb/source/API/SBCompileUnit.cpp
  lldb/test/API/python_api/compile_unit/Makefile
  lldb/test/API/python_api/compile_unit/TestCompileUnitAPI.py
  lldb/test/API/python_api/compile_unit/main.c

Index: lldb/test/API/python_api/compile_unit/main.c
===
--- /dev/null
+++ lldb/test/API/python_api/compile_unit/main.c
@@ -0,0 +1,25 @@
+int a(int);
+int b(int);
+int c(int);
+
+int a(int val) {
+  if (val <= 1)
+val = b(val);
+  else if (val >= 3)
+val = c(val);
+
+  return val;
+}
+
+int b(int val) { return c(val); }
+
+int c(int val) {
+  return val + 3; // break here.
+}
+
+int main(int argc, char const *argv[]) {
+  int A1 = a(1); // a(1) -> b(1) -> c(1)
+  int B2 = b(2); // b(2) -> c(2)
+  int A3 = a(3); // a(3) -> c(3)
+  return 0;
+}
Index: lldb/test/API/python_api/compile_unit/TestCompileUnitAPI.py
===
--- /dev/null
+++ lldb/test/API/python_api/compile_unit/TestCompileUnitAPI.py
@@ -0,0 +1,44 @@
+"""
+Test SBCompileUnit APIs.
+"""
+
+import lldb
+from lldbsuite.test.decorators import *
+from lldbsuite.test.lldbtest import *
+from lldbsuite.test import lldbutil
+
+
+class CompileUnitAPITestCase(TestBase):
+
+mydir = TestBase.compute_mydir(__file__)
+
+def setUp(self):
+TestBase.setUp(self)
+
+def test(self):
+"""Exercise some SBCompileUnit APIs."""
+self.build()
+
+(target, process, thread, bkpt) = lldbutil.run_to_source_breakpoint(self, 'break here', lldb.SBFileSpec('main.c'))
+self.assertTrue(target, VALID_TARGET)
+self.assertTrue(process, PROCESS_IS_VALID)
+self.assertTrue(bkpt and bkpt.GetNumLocations() == 1,
+VALID_BREAKPOINT)
+
+self.assertTrue(
+thread.IsValid(),
+"There should be a thread stopped due to breakpoint condition")
+frame0 = thread.GetFrameAtIndex(0)
+line_entry = frame0.GetLineEntry()
+
+sc_list = target.FindCompileUnits(line_entry.GetFileSpec())
+self.assertGreater(sc_list.GetSize(), 0)
+
+main_cu = sc_list.compile_units[0]
+self.assertTrue(main_cu.IsValid(), "Main executable CU is not valid")
+
+self.assertEqual(main_cu.GetIndexForLineEntry(line_entry, True),
+ main_cu.FindLineEntryIndex(0, line_entry.GetLine(),
+   line_entry.GetFileSpec(), True))
+
+
Index: lldb/test/API/python_api/compile_unit/Makefile
===
--- /dev/null
+++ lldb/test/API/python_api/compile_unit/Makefile
@@ -0,0 +1,3 @@
+C_SOURCES := main.c
+
+include Makefile.rules
Index: lldb/source/API/SBCompileUnit.cpp
===
--- lldb/source/API/SBCompileUnit.cpp
+++ lldb/source/API/SBCompileUnit.cpp
@@ -77,6 +77,20 @@
   return sb_line_entry;
 }
 
+uint32_t SBCompileUnit::GetIndexForLineEntry(lldb::SBLineEntry &line_entry,
+ bool exact) const {
+  LLDB_INSTRUMENT_VA(this, line_entry, exact);
+
+  if (!m_opaque_ptr || !line_entry.IsValid())
+return UINT32_MAX;
+
+  LineEntry found_line_entry;
+
+  return m_opaque_ptr->FindLineEntry(0, line_entry.GetLine(),
+ line_entry.GetFileSpec().get(), exact,
+ &line_entry.ref());
+}
+
 uint32_t SBCompileUnit::FindLineEntryIndex(uint32_t start_idx, uint32_t line,
SBFileSpec *inline_file_spec) const {
   LLDB_INSTRUMENT_VA(this, start_idx, line, inline_file_spec);
Index: lldb/include/lldb/API/SBCompileUnit.h
===
--- lldb/include/lldb/API/SBCompileUnit.h
+++ lldb/include/lldb/API/SBCompileUnit.h
@@ -34,6 +34,9 @@
 
   lldb::SBLineEntry GetLineEntryAtIndex(uint32_t idx) const;
 
+  uint32_t GetIndexForLineEntry(lldb::SBLineEntry &line_entry,
+bool exact = false) const;
+
   uint32_t FindLineEntryIndex(uint32_t start_idx, uint32_t line,
   lldb::SBFileSpec *inline_file_spec) const;
 
Index: lldb/bindings/interface/SBCompileUnit.i
===
--- lldb/bindings/interface/SBCompileUnit.i
+++ lldb/bindings/interface/SBCompileUnit.i
@@ -67,6 +67,22 @@
 lldb::SBLineEntry
 GetLineEntryAtIndex (uint32_t idx) const;
 
+%feature("docstring", "
+ Get the index for a provided line entry in this compile unit.
+
+ @param[in] line_entry
+The SBLineEntry obje

[Lldb-commits] [PATCH] D125434: Make a more convenient way to allow Darwin users to ignore certain Mach Exceptions

2022-05-11 Thread Will Hawkins via Phabricator via lldb-commits 
hawkinsw added a comment.

I hope that those minor edits help at least a little!




Comment at: lldb/source/Plugins/Platform/MacOSX/PlatformMacOSXProperties.td:14
+ "(e.g. 'EXC_BAD_ACCESS|EXC_BAD_INSTRUCTION'). "
+ "lldb will instead stop on the BSD signal the exception was converted"
+ " into, if there is one.">;





Comment at: lldb/source/Plugins/Platform/MacOSX/PlatformMacOSXProperties.td:15
+ "lldb will instead stop on the BSD signal the exception was converted"
+ " into, if there is one.">;
+}




Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D125434

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