[Lldb-commits] [PATCH] D70272: [-gmodules] Let LLDB log a warning if the Clang module hash mismatches.

Pavel Labath via Phabricator via lldb-commits lldb-commits at lists.llvm.org
Fri Nov 15 09:21:04 PST 2019


labath added inline comments.


================
Comment at: lldb/include/lldb/Symbol/SymbolFile.h:283-285
+  /// Return a hash for this symbol file, such as a dwo_id.
+  virtual llvm::Optional<uint64_t> GetSymbolHash() { return {}; }
+  
----------------
aprantl wrote:
> labath wrote:
> > Can we remove this and put a cast in `SymbolFileDWARF::UpdateExternalModuleListIfNeeded` instead? It looks like that function should check that it has really found a dwarf file (and not a pdb for instance) anyway...
> > Can we remove this and put a cast in SymbolFileDWARF::UpdateExternalModuleListIfNeeded instead?
> 
> We don't have a mechanism to dynamic-cast between SymbolFiles at the moment and I think it's difficult to add one, since it's a base class of an open-ended plugin hierarchy. We could require all plugins to register in a global enum if we don't care about extensibility. I also thought about each class identifying itself via a string that is its class name, but then we couldn't implement casting to a base-class easily.
> 
> If you have any idea for how to do this elegantly I'm more than happy to implement it.
> 
> > It looks like that function should check that it has really found a dwarf file (and not a pdb for instance) anyway...
> 
> Technically, yes, but you'd need DWARF that encodes the path of a PDB to get into that situation, so I'm not super concerned about this.
> If you have any idea for how to do this elegantly I'm more than happy to implement it.

I know at least of two ways of doing that:
- the "old" way. This is pretty similar to your string approach and involves doing something like:
```
if (symfile->GetPluginName() == SymbolFileDWARF::GetPluginNameStatic())
  static_cast<SymbolFileDWARF*>(symfile)->stuff()
```
and probably doesn't require any extra coding (the presence of SymbolFileDWARFDebugMap makes things a bit complicated, but I don't think you need that here(?))
- for the new way, you can look at how we've implemented open-ended casting hierarchies in other plugins (last example here: D70070). This works with llvm::dyn_cast and everything. Not all plugins support that yet, but it is a direction we're going right now.


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D70272/new/

https://reviews.llvm.org/D70272





More information about the lldb-commits mailing list