[Lldb-commits] [PATCH] D12291: Add split dwarf support to SymbolFileDWARF

Tamas Berghammer via lldb-commits lldb-commits at lists.llvm.org
Tue Sep 1 05:13:25 PDT 2015


tberghammer added a comment.

Added some inline comments to explain some implementation decisions


================
Comment at: include/lldb/Symbol/ObjectFile.h:372
@@ -371,3 +371,3 @@
     virtual SectionList *
-    GetSectionList ();
+    GetSectionList (bool update_module_section_list = true);
 
----------------
We create all of the dwo object files with the same module what we used for the executable object file (belongs to them). Because of it we have several section with the same section name (several dwo file + object file) what can't be stored inside a single module.

This check is to disable adding the sections in the dwo object file into the modules section list because they will be fetched by SymbolFileDWARFDwo::GetCachedSectionData what handles it correctly.

If we want to avoid it we have to create a separate module for each dwo file and then somehow link them together in a way that we can search for a section in both modules (because the dwo file uses sections from the main object file). I think implementing it that way would be significantly worse and I don't see any good option to handle section list fetching in a better way without creating an ObjectFileELFDwo class just because of it (what will have to be constructed separately because the plugin system have no efficient way to select it).

================
Comment at: source/Plugins/SymbolFile/DWARF/SymbolFileDWARF.cpp:3706-3708
@@ -3738,2 +3705,5 @@
 {
+    if (die.GetDWARF() != this)
+        return die.GetDWARF()->ParseVariableDIE(sc, die, func_low_pc);
+
     VariableSP var_sp;
----------------
This check is necessary because we will call this function on a SymbolFileDWARF fetched from the symbol vendor held by the module what will be the object file while the DWARFDIE will come from a variable's user_id_t.

Pushing this call up to the call stack is not possible (this is the first point in the call chain where this check make sense). If we really want to avoid this check here, then we have to move this function into DWARFCompileUnit or into DWARFDIE where we will have exactly the same check, but the reference for the SymbolFileDWARF members will be a bit more verbose.


http://reviews.llvm.org/D12291





More information about the lldb-commits mailing list