<div dir="ltr">I generally try to stay away from debug info, but since I ended up working on the accelerator tables, and I am about to embark on the lldb part of that project I figure I should chime in. I am mostly speaking to the "using llvm libraries for parsing" part of the discussion, I don't have an opinions on the refactorings per se.<div><br></div><div>My plan for getting the new accelerator table support into lldb was to reuse the parser implementation in the llvm's DebugInfo library. The nice thing about it is that it's completely self-contained (it just needs two blobs of data for the .debug_names and .debug_str sections), so I'm hoping that should be fairly easy to accomplish, and land us with the first case of reusing the llvm libraries for debug info parsing. Although starting with the accelerator tables may be a bit upside-down, I think that the second case for using llvm parsers could be to replace the existing apple_names parsers in lldb (again, because the llvm implementations are fairly stand-alone).</div><div><br></div><div>Now, to get these .debug_names into lldb, I'm going to need to do some refactoring of my own (abstracting the way we index things). I haven't looked at this in more detail yet, but I'm hoping that I can stay clear of the ongoing work on dwz&type units, as all of this happens in SymbolFileDWARF, which you don't seem to touch that much. I'll know more about that once I start doing it.</div><div><br></div><div>cheers,</div><div>pavel<br><div><br></div><div><br></div></div></div><br><div class="gmail_quote"><div dir="ltr">On Sat, 7 Apr 2018 at 10:04, Jan Kratochvil <<a href="mailto:jan.kratochvil@redhat.com">jan.kratochvil@redhat.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On Sat, 07 Apr 2018 00:52:26 +0200, Greg Clayton wrote:<br>
> Take look at how LLVM does it. I believe my changes mirror that approach.<br>
<br>
LLVM does not support partial units so there is nothing to look at there.<br>
<br>
<br>
> DWARFUnit should be the base class for anything that needs to hand out DIEs.<br>
<br>
That's OK for partial units.<br>
<br>
<br>
> Any specializations should be inheriting from DWARFUnit, like both<br>
> DWARFCompileUnit and DWARFTypeUnit.<br>
<br>
I see now the source of misunderstanding:<br>
<br>
DWARFCompileUnit = DW_TAG_compile_unit<br>
DWARFTypeUnit = DW_TAG_type_unit<br>
DWARFPartialUnit != DW_TAG_partial_unit<br>
                ^^^^<br>
BTW DW_TAG_imported_unit is importing (="caller") tag, not a unit (="callee").<br>
<br>
DW_TAG_partial_unit gets read in (by<br>
DWARFDebugInfo::ParseCompileUnitHeadersIfNeeded) as DWARFCompileUnit because<br>
there is no quick enough way to find the difference.  It would require reading<br>
the first DIE tag which means to read and decode .debug_abbrev for each unit<br>
being scanned.<br>
<br>
DWARFPartialUnit is used only as a remapping of DWARFCompileUnit to a new<br>
offset without any new data (there is stored only a new remapped offset whose<br>
value is only made up internally in LLDB) at the moment someone uses<br>
DW_TAG_imported_unit for it - at that moment we easily know that unit has to<br>
be DW_TAG_partial_unit.<br>
<br>
Therefore DWARFCompileUnit and DWARFTypeUnit both contain some their own data.<br>
But DWARFPartialUnit is just a remapping of DWARFCompileUnit (containing<br>
DW_TAG_partial_unit) to a new offset without any new data. Particularly<br>
m_die_array is not in DWARFPartialUnit.<br>
<br>
DWARFTypeUnit can be recognized easily as it is either in .debug_types<br>
(<=DWARF-4) or the unit header contains DW_UT_type (>=DWARF-5).<br>
DWARFPartialUnit (for DW_TAG_partial_unit) cannot be recognized easily first.<br>
Besides that one would need then some DWARFRemappedPartialUnit for what I use<br>
DWARFPartialUnit now.<br>
<br>
I have implemented it according to your advice from this mail - at least<br>
according to how I understood it:<br>
        [lldb-dev] RFC for DWZ = DW_TAG_imported_unit + DWARF-5 supplementary files<br>
        <a href="https://lists.llvm.org/pipermail/lldb-dev/2017-August/012664.html" rel="noreferrer" target="_blank">https://lists.llvm.org/pipermail/lldb-dev/2017-August/012664.html</a><br>
<br>
It does not try to share anything at AST level, it only shares DWARF data (and<br>
thus DWARFCompileUnit). Given that DWZ finds arbitrary unique DWARF subtrees<br>
I find more logical to decode it at DWARF (and not at AST) level.<br>
<br>
You wrote:<br>
# The drawback is this won't allow sharing /tmp/shared1 or /tmp/shared2<br>
# between two different top level DWARF files, but it does allow one<br>
# clang::ASTContext to be used between all of them.<br>
<br>
In my implementation /tmp/shared1<br>
(/usr/lib/debug/.dwz/coreutils-8.27-20.fc27.x86_64) is shared between multiple<br>
*.so files (which use DW_TAG_imported_unit) at DWARF level, also<br>
clang::ASTContext is shared.<br>
<br>
<br>
# SymbolFileDWARFDebugMap makes it lldb::user_id_t contain the CU index in the<br>
# top 32 bits, and the DIE offset within that .o file's DWARF in the bottom 32<br>
# bits. You could do something similar in your case where the top 32 bits is<br>
# the index of the DWARF file in the "dwarf[]" array that would be maintained<br>
# in a new SymbolFileDWARFDWZ subclass.<br>
<br>
DW_TAG_imported_unit+DW_TAG_partial_unit can be also used for optimization of<br>
a single file (without /usr/lib/debug/.dwz/* file which is used exclusively<br>
for DW_TAG_partial_unit entries). Additionally the tags can be also used for<br>
recursive inclusion. I haven't found how to use the top 32 bits for that.<br>
I just reserve new remapped offset space for each DW_TAG_imported_unit (in the<br>
bottom 32 bits).<br>
<br>
I tried first to implement dw_offset_t caller (=unit with<br>
DW_TAG_imported_unit) to be tracked along any dw_offset_t DIE offset but that<br>
would require huge changes of the DWARF parsing code everywhere.  Also it<br>
cannot work well given the inclusion is recursive (so we would need<br>
std::vector<dw_offset_t> of the callers stack).<br>
<br>
<br>
<br>
> I have no idea what are in your other patches<br>
<br>
OK, so there was a gross misunderstanding and my DWARFUnit implemented<br>
something very different from what you expected+approved. I am sure fine with<br>
that but I needed to understand first why you did that big screw up of my<br>
carefully coded patch.<br>
<br>
<br>
> > This is how DWARFPartialUnit works, it is only a DWARFCompileUnit remapped to<br>
> > new offset.  I do not see how to implement it transparently without the<br>
> > accessor (and without needlessly copying all the data fields many times into<br>
> > each DWARFPartialUnit instance).<br>
><br>
> What extra functions are needed for a partial unit that can't be done in<br>
> a DWARFCompileUnit? Seems like they both contain things, but the partial<br>
> unit can be referenced from compile units.<br>
<br>
DWARFPartialUnit is only a remapping, not really a representation of DWARF<br>
file data.  So DWARFPartialUnit cannot contain its own m_die_array, m_version<br>
and other data members you have moved back to DWARFUnit.<br>
<br>
<br>
> As we are saying, we are trying to make the layering more like LLVM's<br>
> layering, so that is what I meant by "fix the layering". I believe we should<br>
> strive for being more like LLVM so that any transition can happen without<br>
> major re-organization of the DWARF code later. So I would like the get the<br>
> ok the revert the revert if you on board with what my suggestions are in the<br>
> paragraph. I know this will require modifications to your patches and<br>
> apologize for that.<br>
><br>
> Let me know what you think,<br>
<br>
I would like to know what is the approved plan / upstreaming order regarding<br>
all the planned changes:<br>
<br>
(1) Your DWARFTypeUnit patch - it makes it more aligned to LLVM DWARFUnits.<br>
(2) My DWZ patch - it is a new feature with no counterpart in LLVM DWARFUnits.<br>
(3) Replacement of LLDB DWARFUnits with LLVM DWARFUnits.<br>
<br>
I can sure work even on (3) but after half a year of work on DWZ support which<br>
completely blocks LLDB for Red Hat usage (as Red Hat requires "upstream first"<br>
to prevent heavy forks like what happened for Red Hat GDB) it makes the DWZ<br>
upstreaming possibility too far for me to start refactoring LLDB for (3) first<br>
- before upstreaming (2).<br>
<br>
<br>
Thanks,<br>
Jan<br>
</blockquote></div>