jankratochvil added inline comments.
================
Comment at: source/Plugins/SymbolFile/DWARF/DWARFUnit.h:34
class DWARFUnit {
+ friend class DWARFCompileUnit;
+
----------------
clayborg wrote:
> DWARFCompileUnit inherits from this class. This isn't needed right?
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.
https://reviews.llvm.org/D42892
_______________________________________________
lldb-commits mailing list
lldb-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
