This is an archive of the discontinued LLVM Phabricator instance.

DWZ 01/11: DWARFUnit split out of DWARFCompileUnit
ClosedPublic

Authored by jankratochvil on Nov 26 2017, 4:56 AM.

Details

Summary

DW_TAG_partial_unit can be then presented by DWARFPartialUnit also inherited from DWARFUnit.

All DWZ patches are also applied in: git clone -b dwz git://git.jankratochvil.net/lldb

Diff Detail

Event Timeline

jankratochvil created this revision.Nov 26 2017, 4:56 AM
jankratochvil retitled this revision from DWZ: DWARFCompileUnit split to DWARFCompileUnitData to DWZ 03/12: DWARFCompileUnit split to DWARFCompileUnitData.
clayborg added inline comments.Nov 27 2017, 10:11 AM
source/Plugins/SymbolFile/DWARF/DWARFCompileUnit.h
114

Is there a reason this is a member variable that I am not seeing? Seems we could have this class inherit from DWARFCompileUnitData. I am guessing this will be needed for a future patch?

jankratochvil marked an inline comment as done.Nov 29 2017, 12:49 PM
jankratochvil added inline comments.
source/Plugins/SymbolFile/DWARF/DWARFCompileUnit.h
114

Yes, future patch D40474 contains a new constructor so multiple DWARFCompileUnit then point to single DWARFCompileUnitData. Sure that happens only in the case ot DW_TAG_partial_unit (one DWARFCompileUnit is read from a file while other DWARFCompileUnit are remapped instances with unique offset as used from units which did use DW_TAG_imported_unit for them).
DWARFCompileUnit(DWARFCompileUnitData *data, DWARFCompileUnit *main_cu);

clayborg requested changes to this revision.Nov 29 2017, 1:41 PM

Take a look how the LLVM DWARF parser handles its units. It makes a DWARFUnit base class that the compile unit inherits from. That can then be used for type units and compile units.

source/Plugins/SymbolFile/DWARF/DWARFCompileUnit.h
19–21

Just make this enum DWARFProducer and get rid of the DWARFCompileUnitDecls class.

21

remove DWARFCompileUnitDecls and just use DWARFProducer

23

Remove DWARFCompileUnitDecls and just use DWARFProducer

23

The LLVM DWARF parser calls this class a DWARFUnit. We should probably do the same.

114

We should just have an instance of this in this class and add a virtual function to retrieve it. Then we make a DWARFPartialUnit that subclasses this and has its own extra member variable and can use either one when it makes sense. Not a fan of just having a dangling pointer with no clear ownership. There is no "delete m_data" anywhere?

This revision now requires changes to proceed.Nov 29 2017, 1:41 PM
jankratochvil marked an inline comment as done.Nov 29 2017, 2:04 PM
jankratochvil added inline comments.
source/Plugins/SymbolFile/DWARF/DWARFCompileUnit.h
114

The DWARFCompileUnitData *m_data content is being held in: std::forward_list<DWARFCompileUnitData> SymbolFileDWARF::m_compile_unit_data_list as I hope/believe a DWARFCompileUnit is never deleted until whole SymbolFileDWARF is deleted. I did not use std::shared_ptr<DWARFCompileUnitData> DWARFCompileUnit::m_data as shared_ptr is both memory and lock-instruction-performance expensive.

jankratochvil added inline comments.Dec 2 2017, 12:31 PM
source/Plugins/SymbolFile/DWARF/DWARFCompileUnit.h
114

Then we make a DWARFPartialUnit that subclasses this

We cannot because DWARFCompileUnit is constructed by DWARFDebugInfo::ParseCompileUnitHeadersIfNeeded->DWARFCompileUnit::Extract and it currently does not know whether it is DW_TAG_compile_unit or DW_TAG_partial_unit. But then DWARFCompileUnit::Extract could read even the very first DIE and save it for later use. Then DWARFCompileUnit::ExtractDIEsIfNeeded would not need the bool cu_die_only parameter and altogether I could also drop my D40471. Do you agree?
(This whole DWARF units parsing across the file is not too efficient anyway, there should be some index in use; and I would prefer the DWARF-5 one over the Apple one.)

DWARFCompileUnitData is no more, there is now DWARFUnit with virtual method Data() to reference its inherited DWARFCompileUnit. I think it will make it more mergeable with LLVM DWARFUnit.

jankratochvil retitled this revision from DWZ 03/12: DWARFCompileUnit split to DWARFCompileUnitData to DWZ 02/12: DWARFUnit split out of DWARFCompileUnit.Feb 4 2018, 9:20 AM
jankratochvil edited the summary of this revision. (Show Details)

This patch only tries to move code without changing it in any way (except for some Data() references required for DWARFCompileUnit members access from DWARFUnit).

jankratochvil retitled this revision from DWZ 02/12: DWARFUnit split out of DWARFCompileUnit to DWZ 01/11: DWARFUnit split out of DWARFCompileUnit.
jankratochvil marked 3 inline comments as done.

bugfix

clayborg accepted this revision.Mar 12 2018, 8:44 AM

This is fine. Lets start with this and then worry about each next patch. 02/11 next.

This revision is now accepted and ready to land.Mar 12 2018, 8:44 AM
davide accepted this revision.Mar 12 2018, 9:18 AM
davide added a subscriber: davide.

This is No functional change, right (just code churn)? If so, LGTM.

This is No functional change, right (just code churn)?

Right.

This revision was automatically updated to reflect the committed changes.