[Lldb-commits] [lldb] [LLDB][Telemetry]Define DebuggerTelemetryInfo and related methods (PR #127696)

Pavel Labath via lldb-commits lldb-commits at lists.llvm.org
Fri Feb 28 03:54:05 PST 2025


================
@@ -987,6 +1005,20 @@ void Debugger::Clear() {
   //     static void Debugger::Destroy(lldb::DebuggerSP &debugger_sp);
   //     static void Debugger::Terminate();
   llvm::call_once(m_clear_once, [this]() {
+    lldb_private::telemetry::ScopeTelemetryCollector helper;
+    if (helper.TelemetryEnabled()) {
+      // TBD: We *may* have to send off the log BEFORE the ClearIOHanders()?
+      helper.RunAtScopeExit([&helper, this]() {
+        lldb_private::telemetry::TelemetryManager *manager =
+            lldb_private::telemetry::TelemetryManager::GetInstance();
+        lldb_private::telemetry::DebuggerInfo entry;
+        entry.debugger = this;
+        entry.exit_desc = {0, ""}; // If we are here, there was no error.
----------------
labath wrote:

Okay, but if we're not actually sending the crash reports upstream (which I think is the right choice), could we also avoid prescribing how a downstream implementation should represent those crashes. For example, someone might want to send the backtrace in a more structured form (list of addresses?) instead of a string. Fixed-size entries are a lot easier to handle in an async-signal context than a string (which basically cannot be used safely).

IOW, can we drop the `exit_desc` field from this struct?

https://github.com/llvm/llvm-project/pull/127696


More information about the lldb-commits mailing list