================
@@ -761,12 +764,27 @@ void Debugger::InstanceInitialize() {
 
 DebuggerSP Debugger::CreateInstance(lldb::LogOutputCallback log_callback,
                                     void *baton) {
+  lldb_private::telemetry::ScopeTelemetryCollector helper;
   DebuggerSP debugger_sp(new Debugger(log_callback, baton));
+
+  if (helper.TelemetryEnabled()) {
+    helper.RunAtScopeExit([&]() {
+      lldb_private::telemetry::TelemetryManager *manager =
+          lldb_private::telemetry::TelemetryManager::GetInstance();
+      lldb_private::telemetry::DebuggerInfo entry;
+      entry.debugger = debugger_sp.get();
+      entry.start_time = helper.GetStartTime();
+      entry.end_time = helper.GetCurrentTime();
+      manager->AtDebuggerStartup(&entry);
----------------
oontvoo wrote:

> This still feels rather boilerplate-y. `debugger`, `start_time` and 
> `end_time` are present in every field, and declaring and sending an event is 
> also something you need to do every time. What if the interface was something 
> like:
> 
> ```
> ScopeTelemetryCollector<DebuggerInfo> telemetry_helper(debugger_sp.get());
> ```
> 
> where the object automatically fills declares the object, fills in the common 
> fields and then sends it off in the destructor? It can provide some accessor 
> to the object contained within it to let the code set any additional fields.


How does the helper object know which fields to fill in?
For this specific case,  it's not much - just needed the debugger_sp. But for 
other cases (eg., commandinfo, it needs a bunch of local fields from callsite).
I'm worry we'll be adding too many layer of indirection. 



> 1. ditch `AtDebuggerStartup` and have it always call `dispatch` (the 
> customization can happen in `preDispatch`)

These `AtDebuggerStartup`, etc, are how the downstream code can have overriding 
impl functions to collect additional data for each scenario.  The `preDispatch` 
is common for ALL scenarios 
(debugger-startup/shutdown/command-executation/target-load/etc). 

https://github.com/llvm/llvm-project/pull/127696
_______________________________________________
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits

Reply via email to