3a50cfeba5
This patch is the first part in a patch series that will allow enabling/disabling InstrumentationRuntime plugins in a running debug session. This part adds the `--domain` flag to the `enable`, `disable`, `list` sub commands of `plugin` shell command and plumbs the value of this flag to where it will be needed in a subsequent patch. From the user perspective the flag does nothing useful yet because all values passed to the flag except `global` (the default and what represents LLDB's existing behavior) are rejected. Subsequent patches will allow the flag to do something useful. The `--domain` flag adds a notion of "domain" to plugins with respect to their enablement. Previously all plugins were treated as global and have their enablement stored globally. This is despite the fact that some plugins clearly are not global. For example the `instrumentation-runtime` plugins clearly exist on a per-target basis (the instances of the `InstrumentationRuntime` exist in each process). In addition to this plugins being "global" means instances of the `Debugger` instance are not properly isolated from each other. This PR is a stepping stone towards fixing these design problems. The PR introduces three different domains for plugins: * `global` - Enablement of the plugin can be controlled globally. This is the existing behavior of all LLDB plugins. * `debugger` - Enablement of the plugin can be controlled on a per `Debugger` basis. * `target` - Enablement of the plugin can be controlled on a per `Target` basis. These values are encoded in the new `PluginDomainKind` enum. It is important to note that the design in this PR means a plugin can support more than one domain. In particular in future patches when `instrumentation-runtime` plugins gain support for more than just the `global` domain they will support the `debugger` and `target` domain as well. The key reason that the `instrumentation-runtime` plugins need to support more than one domain is that the plugins need a default enablement value **before** the target exists. That default value will need to come from the `global` domain. Architecturally it should probably come from the `debugger` domain instead but refactoring enablement into Debugger instances is much too large a refactor for this patch series and is a problem that can be tackled later. This patch modifies the `PluginNamespace` struct to: * Store the set of domains supported by the namespace and provided some helper methods to determine what is supported. * Store one of two callbacks. Either `SetPluginEnabledGlobalDomain` (the existing function interface used by most plugins) or `SetPluginEnabledAllDomains` (a new interface used by `InstrumentationRuntime` plugins). In this patch the `InstrumentationRuntime` plugins use the new `SetPluginEnabledAllDomains` function interface for enablement (i.e. the interface of `PluginManager::SetInstrumentationRuntimePluginEnabled` has changed) which passes the `Debugger` instance that made the request and the domain the user provided to the `plugin enable` or `plugin disable` command. To make this patch easier to review the `PluginManager::SetInstrumentationRuntimePluginEnabled` function actually rejects all domains except `global` to keep the behavior change down to a minimum. Proper support for enabling/disabling instrumentation-runtime plugins in the `target`, and `debugger` domains will be implemented in a subsequent patch. The `plugin list` command implementations also reject any domain that isn't `global`. Support for other domains will be added in the subsequent patch that adds support for other domains in the `instrumentation-runtime` plugins. The `plugin enable`, `plugin disable`, `plugin list` commands will use the `global` domain by default so that there is no behavior change for existing workflows. Two new shell tests are included that exercise the new code paths: * `command-plugin-enable-disable-domain-flag.test` validates that `--domain global` works for both global-only and multi-domain plugin namespaces, and that `--domain debugger` and `--domain target` are correctly rejected for now. * `command-plugin-list-domain-flag.test` validates the same behavior for the list command in both text and JSON output modes. I am not experienced at adding flags to LLDB shell commands so I had Claude Code write that part and also help write test cases. Assisted-by: Claude Code rdar://167725878
17 KiB
17 KiB