Page MenuHomePhabricator

DWZ 02/11: Move the codebase to use: DWARFCompileUnit -> DWARFUnit

Authored by jankratochvil on Feb 4 2018, 9:23 AM.



Now the codebase can use the DWARFUnit superclass. It will make it later seamlessly work also with DWARFPartialUnit for DWZ.

This patch is only a search-and-replace easily undone, nothing interesting in it.

All DWZ patches are also applied in: git clone -b dwz git://

Diff Detail


Event Timeline

jankratochvil created this revision.Feb 4 2018, 9:23 AM
jankratochvil retitled this revision from DWZ 03/12: Move the codebase to use: DWARFCompileUnit -> DWARFUnit to DWZ 02/11: Move the codebase to use: DWARFCompileUnit -> DWARFUnit.
jankratochvil edited the summary of this revision. (Show Details)
davide accepted this revision.Mar 12 2018, 9:20 AM
davide added a subscriber: davide.


This revision is now accepted and ready to land.Mar 12 2018, 9:20 AM
clayborg accepted this revision.Mar 12 2018, 10:33 AM
clayborg added inline comments.
34 ↗(On Diff #135048)

DWARFCompileUnit inherits from this class. This isn't needed right?

jankratochvil added inline comments.Mar 18 2018, 12:12 PM
34 ↗(On Diff #135048)

It is needed now as DWARFCompileUnit::GetFunctionAranges() calls m_dwo_symbol_file->GetCompileUnit()->DIEPtr();:

llvm-git/tools/lldb/source/Plugins/SymbolFile/DWARF/DWARFCompileUnit.cpp: In member function ‘const DWARFDebugAranges& DWARFCompileUnit::GetFunctionAranges()’:
llvm-git/tools/lldb/source/Plugins/SymbolFile/DWARF/DWARFCompileUnit.cpp:504:59: error: ‘const DWARFDebugInfoEntry* DWARFUnit::DIEPtr()’ is protected within this context
       const DWARFDebugInfoEntry *dwo_die = dwo_cu->DIEPtr();
In file included from llvm-git/tools/lldb/source/Plugins/SymbolFile/DWARF/DWARFCompileUnit.h:13:0,
                 from llvm-git/tools/lldb/source/Plugins/SymbolFile/DWARF/DWARFCompileUnit.cpp:10:
llvm-git/tools/lldb/source/Plugins/SymbolFile/DWARF/DWARFUnit.h:173:30: note: declared protected here
   const DWARFDebugInfoEntry *DIEPtr();

DIEPtr() cannot be even protected, it would need to be public. I do not like moving DWARFCompileUnit::GetFunctionAranges() implementation to DWARFUnit to access it as private as after such move it needs to access members by the Data() indirection and there is no need of GetFunctionAranges() for DWZ DWARFPartialUnit (as those units cannot contain code).
Going to check in the split now when it is approved, I can fix up the friend class upon request later, thanks.

This revision was automatically updated to reflect the committed changes.