tberghammer added a comment. If I understand you correctly then you are suggesting to create a class like SymbolFileDWARFDebugMap for handling object files with dwo files. I think that approach is practically have the same code flow as the current one (one symbol file which one stores a list of sub symbol files). The 2 main difference is having a separate top level symbol file class for it makes the abstraction a bit cleaner (we have to refer to the debug map symfile several place in SymbolFileDWARF) but also require more code where some of it is code duplication. With dwo files it is a bit more complicated to solve is because there is no easy way do find out if a file contains dwo entries or not and it is possible for an object file to have some compile unit with dwo entry and some compile unit what is present in the main symbol file (I don't think it is a common scenario).
If we would like to go in the direction with abstracting out the dwo handling more, then I would suggest to change the NameToDIE arrays to store lldb::user_id_t where the 32MSB represents the dwarf compile unit index and 32LSB is the DIE offset. Then each function what currently find a (dwarf) compile unit based on die offset can use the compile unit index while the rest of the dwo handling can be abstracted out into the DWARCompileUnit/DWARFDebugInfoEntry classes (+ possibly a few more DWARF class). My only concern with this approach is that we start storing 2 different information in the higher bits of user_id_t what can cause problems. (Is there a reason we want to abstract this feature out considering that it is almost standard dwarf?) All in all I don't want to have a separate top level symbol file (referenced by a SymbolVendor) for handling dwo files because I think it is more work to maintain it and don't give us too much benefits. Next to it I am happy with most possible approach. If you would like to help me with implementing the split dwarf handling then I welcome any help but currently I can focus this issue in most of my time and would like to get it working (with 100% test pass rate) before mid September so I would like to try to avoid situations where we start waiting on each other. http://reviews.llvm.org/D12291 _______________________________________________ lldb-commits mailing list lldb-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
