> On Apr 10, 2018, at 2:13 PM, Jan Kratochvil via Phabricator 
> <revi...@reviews.llvm.org> wrote:
> jankratochvil added a comment.
> In https://reviews.llvm.org/D32167#1062618, @clayborg wrote:
>> we should be using the AST importer to import the type from that file into 
>> the AST for the current DWARF file. We do have done this with -gmodules 
>> already, so DWZ shouldn't be that different.
> Is AST usable for imported declarations of `DW_TAG_variable`, 
> `DW_TAG_subprogram`, `DW_TAG_enumeration_type`+`DW_TAG_enumerator`s etc.? 
> Still imported `DW_TAG_partial_unit` cannot contain any code or data 
> addresses which may make it easier for AST.


> ================
> Comment at: source/Plugins/SymbolFile/DWARF/SymbolFileDWARF.cpp:595
> +      uint64_t debug_info_size = get_debug_info_data().GetByteSize();
> +      data_segment.m_data.OffsetData(debug_info_size);
> +    }
> ----------------
> clayborg wrote:
>> jankratochvil wrote:
>>> I do not like this `DWARFDataExtractor::m_start` modification, it sort of 
>>> corrupts the `DataExtractor` and various operations stop working then - 
>>> such as `DWARFDataExtractor::GetByteSize()`. DWZ patch makes from current 
>>> `dw_offset_t` a virtual (remapped) offset and introduces new physical file 
>>> section offset which is looked up for data extraction. The file offset is 
>>> represented as `DWARFFileOffset` in D40474, instead of `bool m_is_dwz;` 
>>> there could be some `enum { DEBUG_INFO, DEBUG_TYPES, DWZ_DEBUG_INFO } 
>>> m_where;` instead.
>> This means that this diff doesn't affect all of the other DWARF code. 
>> Nothing in .debug_types will refer to anything else (not DW_FORM_ref_addr, 
>> or any external references). So this trick allows us to just treat 
>> .debug_info as if .debug_types was appended to the end since nothing in 
>> .debug_types refers to any DIE outside of its type unit. This also mirrors 
>> what will actually happen with DWARF5 when all of the data is contained 
>> inside of the .debug_info section. This allows each DIE to have a unique 
>> "ID". Any other change requires a lot of changes to the DWARF parser and 
>> logic. So I actually like this feature. We can fix the GetByteSize() if 
>> needed. Basically every object in DWARf right now must be able to make a 
>> unique 64 bit unsigned integer ID in some way that we can get back to that 
>> info and partially parse more. These are handed out as lldb::user_id_t 
>> values for types, functions and more. Each flavor of DWARF will encode what 
>> they want into here. The normal DWARF it is just the absolute offset within 
>> the .debug_info. With .debug_types we just add the size of the .debug_info 
>> to the ID. For DWARF in .o files on Darwin, we encode the compile unit index 
>> into the top 32 bits and the DIE offset into the lower, DWO does something 
>> just as DWZ will need to. DWARFFileOffset doesn't mean much if there are 
>> multiple files. We have many competing type uniquing/debug info size 
>> reduction strategies being employed here. I can't believe we have DWO, DWZ, 
>> and debug types... But we have to make them all work. We can't just use the 
>> absolute file offset because DWO used external files where the file offsets 
>> could be the same in the external .o files... Not sure how this works with 
>> DWZ or what the best option is. I will read up on DWZ so I can propose some 
>> viable options. But each new flavor of the day that gets added the DWARF 
>> parser is adding a bunch of logic and edge cases. If two technologies (DWZ + 
>> DWO, DWZ + debug_types, etc) are used together, we need to ensure they can.
>> Any other change requires a lot of changes to the DWARF parser and logic. So 
>> I actually like this feature.
> I agree it is a fine quick&dirty hack. Just if my DWZ support gets accepted 
> later anyway then this `.debug_types` feature could be implemented by its 
> framework in a clean way (as a regular DIEs remapping which is required for 
> DWZ anyway).

Now that I understand the DWZ format, I will try and rework this patch by 
modifying DWARFDataExtractor so it works for both our cases. Then you should be 
able to just open your partial units as a normal DWARF file with no 
differences, we just tweak the DWARFDataExtractor when the main file loads the 
external file and nothing more needs to be done.

>> If two technologies (DWZ + DWO, DWZ + debug_types, etc) are used together, 
>> we need to ensure they can.
> `DWZ + DWO` do not make sense to me.  I haven't tried to use DWZ for DWO but 
> DWZ finds common DWARF subtrees typically across CUs so it would not find 
> much.
> `DWZ + debug_types` is explicitly supported by the DWZ tool although that is 
> IMO for compatibility only, DWZ can make the common type references slightly 
> smaller than debug_types. I will sure need to implement debug_types support 
> into my DWZ-for-LLDB patchset later.

Ok, let me try to rework this patch so it can work for both and I'll let you 
know how it goes.
> https://reviews.llvm.org/D32167

lldb-commits mailing list

Reply via email to