[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