[Lldb-commits] [lldb] Define Telemetry plugin for LLDB. (PR #126588)

Vy Nguyen via lldb-commits lldb-commits at lists.llvm.org
Fri Feb 14 19:25:29 PST 2025


oontvoo wrote:

> > The (baroque) way that the other plugins work serves two purposes:
> > 
> > 1. controlling the type (class) of the plugin being created based on some runtime property
> > 2. creating an arbitrary number of plugin instances
> > 
> > For telemetry "plugins", I don't think we want/need (1) because the type of the plugin is determined by the vendor -- at build time. A user can't change that at runtime. They may be able to disable collection, but they can't say "well, today I feel like reporting my telemetry to company `<X>`" and change a setting or something to make that happen. I mean, it's probably doable, but I don't think anyone has that as a requirement (if you do, let us know).
> 
> I don't think anyone has that requirement but I could see a few situations where that could be useful. For example we could have a "textual telemetry" fallback plugin that we use for testing and users could turn on the audit what's being reported. 

This sounds like it could be done via configuration on the `Destination` (ie., where the collected data ended up), rather than the TelemetryManager (plugin) itself. 


> We don't need to inherit from `PluginInterface` as it really doesn't give you anything.

>From my understanding, the benefit of inheriting from the interface is you  can re-use the existing cmake and C++ macros magic for defining vendor impl  - that is, you just put `LLDB_PLUGIN_DEFINE(MyPlugin)` in the vendor code, along with the cmake declaration and you're done! The framework takes care of ensuring the `::Initialize()` is called to set the instance.

> How does that sound to you @oontvoo & @labath?

SG, either way - the simpler the better :)


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


More information about the lldb-commits mailing list