royitaqi wrote: @JDevlieghere I see your point (some learning questions below about the principle).
However, I feel `ObjectFile::SupportsDebugMap()` is still closely tied to a specific plugin (not through compilation, but semantics). Imagine each plugin needs to add such a method into the `ObjectFile` class, then the class will be filled with plugin-specific methods like this, which I feel breaks the API scalability the plugin system wanted. Instead, maybe it's better if we frame "DebugMap" as an `ObjectFileCapability` enum. Other capabilities can be added, too, e.g. does the object file imply split dwarf, etc. Then the API will be `ObjectFile::GetSupportedCapabilities()`. WDYT? (Note: I am trying to think about how does this relate to the `CalculateAbilities()` function in those `SymbolFile` subclasses. I feel they are different, so it should be okay.) -- (my learning question about the principle of "Plugins shouldn't depend on each other") -- I guess I'm missing a lot of context here. From my limited and naive view, there *are* natural connections between different kinds of plugins because how they usually work together in existing systems. E.g. macOS usually use Mach-O files and can use either `SymbolFileDWARF` and `SymbolFileDWARFDebugMap`, but never split-DWARF (dwp/dwo). I don't understand the design principle of "Plugins shouldn't depend on each other". It feels like it's trying to ignore the natural connection between these plugins. I'm guessing we have that principle so as to avoid having to model a complex (and dynamic) dependency problem? (E.g. "A and B" and "B and C" should always work together, but "A and C" should never work together.) https://github.com/llvm/llvm-project/pull/139170 _______________________________________________ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
