clayborg added a comment. If we switch to auto registration of plug-in in the near future there are many things we need to watch out for and some notion of ordering needs to happen. A few examples:
- SymbolFileDWARFDebugMap and SymbolFileDWARF. Right now SymbolFileDWARF comes first and will claim a file before SymbolFileDWARFDebugMap. If SymbolFileDWARFDebugMap comes it will waste time iterating over all symbols in the symbol table, which causes the entire symbol table to be pulled in, and looks linearly for a symbol with type lldb::eSymbolTypeObjectFile, It will also claims it can parse the debug info just as well as SymbolFileDWARF, so it might end up getting used even though we have a dSYM file. So we need a way to avoid this. Right now ordering is used I believe. So the SymbolFileDWARFDebugMap::CalculateAbilities() might need to check if SymbolFileDWARF::CalculateAbilities() has all the abilities first, and just respond with no abilities in that case. - SymbolFileSymtab and any other SymbolFile. SymbolFileSymtab will spend time going through the symbol table looking for symbols that describe any debug info. We want this to come last all the time and use this plug-in as a last resort. - ObjectFile plug-ins can be ordered more efficiently for the current system (have ObjectFileMachO come first on Apple hosts, ObjectFileELF for non windows, ObjectFileCOFF for windows, etc). Not required, but would be nice. - DynamicLoaderStatic vs any target that doesn't have OS, vendor or environment set. , we might need to bolster the plug-in system a bit to be more like the SymbolFile plug-ins. For symbol file plug-ins we have each on calculate abilities and say Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D72751/new/ https://reviews.llvm.org/D72751 _______________________________________________ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
