@@ -56,6 +56,56 @@ subset of LLDB tests (the API tests) use a different system. Refer to the
56
56
`lldb/test <https://github.com/llvm/llvm-project/tree/main/lldb/test >`_ folder
57
57
for examples.
58
58
59
+
60
+ LLDB plugins and their dependencies
61
+ -----------------------------------
62
+
63
+ LLDB has a concept of *plugins *, which are used to provide abstraction
64
+ boundaries over functionality that is specific to a certain architecture,
65
+ operating system, programming language, etc. A plugin implements an abstract
66
+ base class (rarely, a set of related base classes), which is a part of LLDB
67
+ core. This setup allows the LLDB core to remain generic while making it possible
68
+ to support for new architectures, languages, and so on. For this to work, all
69
+ code needs to obey certain rules.
70
+
71
+ The principal rule is that LLDB core (defined as: everything under lldb/source
72
+ *minus * lldb/source/Plugins) must not depend on any specific plugin. The only
73
+ way it can interact with them is through the abstract interface. Explicit
74
+ dependencies such as casting the base class to the plugin type are not permitted
75
+ and neither are more subtle dependencies like checking the name plugin or or
76
+ other situations where some code in LLDB core is tightly coupled to the
77
+ implementation details of a specific plugin.
78
+
79
+ The rule for interaction between different plugins is more nuanced. We recognize
80
+ that some cross-plugin dependencies are unavoidable or even desirable. For
81
+ example, a plugin may want to extend a plugin of the same kind to
82
+ add/override/refine some functionality (e.g., Android is a "kind of" Linux, but
83
+ it handles some things differently). Alternatively, a plugin of one kind may
84
+ want to build on the functionality offered by a specific plugin of another kind
85
+ (ELFCore Process plugin uses ELF ObjectFile plugin to create a process out of an
86
+ ELF core file).
87
+
88
+ In cases such as these, direct dependencies are acceptable. However, to keep the
89
+ dependency graph manageable, we still have some rules to govern these
90
+ relationships:
91
+
92
+ * All dependencies between plugins of the same kind must flow in the same
93
+ direction (if plugin `A1 ` depends on plugin `B1 `, then `B2 ` must not depend on
94
+ `A2 `)
95
+ * Dependency graph of plugin kinds must not contain loops (dependencies like
96
+ `A1->B1 `, `B2->C2 ` and `C3->A3 ` are forbidden because they induce a cycle in
97
+ the plugin kind graph even though the plugins themselves are acyclical)
98
+
99
+
100
+ The first of these rules is checked via CMake scripts (using the
101
+ `LLDB_ACCEPTABLE_PLUGIN_DEPENDENCIES ` property). Dependencies in this category
102
+ are expected and permitted (subject to other constraints such as that dependency
103
+ making sense for the particular pair of plugins). Unfortunately, due to historic
104
+ reasons, not all plugin dependencies follow this rule, which is why we have
105
+ another category called `LLDB_TOLERATED_PLUGIN_DEPENDENCIES `. New dependencies
106
+ are forbidden (even though they are accepted by CMake) and existing ones should
107
+ be removed whereever possible.
108
+
59
109
.. _Error handling :
60
110
61
111
Error handling and use of assertions in LLDB
0 commit comments