[all-commits] [llvm/llvm-project] 9a7262: [lldb][DWARF] Delay struct/class/union definition ...

[Zequan Wu via All-commits]

  Branch: refs/heads/main
  Home:   https://github.com/llvm/llvm-project
  Commit: 9a7262c2601874e5aa64c5db19746770212d4b44
      https://github.com/llvm/llvm-project/commit/9a7262c2601874e5aa64c5db19746770212d4b44
  Author: Zequan Wu <zequanwu at google.com>
  Date:   2024-05-10 (Fri, 10 May 2024)

  Changed paths:
    M lldb/source/Plugins/SymbolFile/DWARF/DWARFASTParser.h
    M lldb/source/Plugins/SymbolFile/DWARF/DWARFASTParserClang.cpp
    M lldb/source/Plugins/SymbolFile/DWARF/DWARFASTParserClang.h
    M lldb/source/Plugins/SymbolFile/DWARF/SymbolFileDWARF.cpp
    M lldb/source/Plugins/SymbolFile/DWARF/SymbolFileDWARF.h
    M lldb/source/Plugins/SymbolFile/DWARF/UniqueDWARFASTType.cpp
    M lldb/source/Plugins/SymbolFile/DWARF/UniqueDWARFASTType.h
    A lldb/test/Shell/SymbolFile/DWARF/delayed-definition-die-searching.test

  Log Message:
  -----------
  [lldb][DWARF] Delay struct/class/union definition DIE searching when parsing declaration DIEs. (#90663)

This is the implementation for
https://discourse.llvm.org/t/rfc-delay-definition-die-searching-when-parse-a-declaration-die-for-record-type/78526.

#### Motivation
Currently, lldb eagerly searches for definition DIE when parsing a
declaration DIE for struct/class/union definition DIE. It will search
for all definition DIEs with the same unqualified name (just
`DW_AT_name` ) and then find out those DIEs with same fully qualified
name. Then lldb will try to resolve those DIEs to create the Types from
definition DIEs. It works fine most time. However, when built with
`-gsimple-template-names`, the search graph expands very quickly,
because for the specialized-template classes, they don’t have template
parameter names encoded inside `DW_AT_name`. They have
`DW_TAG_template_type_parameter` to reference the types used as template
parameters. In order to identify if a definition DIE matches a
declaration DIE, lldb needs to resolve all template parameter types
first and those template parameter types might be template classes as
well, and so on… So, the search graph explodes, causing a lot
unnecessary searching/type-resolving to just get the fully qualified
names for a specialized-template class. This causes lldb stack overflow
for us internally on template-heavy libraries.

#### Implementation
Instead of searching for definition DIEs when parsing declaration DIEs,
we always construct the record type from the DIE regardless if it's
definition or declaration. The process of searching for definition DIE
is refactored to `DWARFASTParserClang::FindDefinitionTypeForDIE` which
is invoked when 1) completing the type on
`SymbolFileDWARF::CompleteType`. 2) the record type needs to start its
definition as a containing type so that nested classes can be added into
it in `PrepareContextToReceiveMembers`.

The key difference is `SymbolFileDWARF::ResolveType` return a `Type*`
that might be created from declaration DIE, which means it hasn't starts
its definition yet. We also need to change according in places where we
want the type to start definition, like `PrepareContextToReceiveMembers`
(I'm not aware of any other places, but this should be a simple call to
`SymbolFileDWARF::FindDefinitionDIE`)

#### Result
It fixes the stack overflow of lldb for the internal binary built with
simple template name. When constructing the fully qualified name built
with `-gsimple-template-names`, it gets the name of the type parameter
by resolving the referenced DIE, which might be a declaration (we won't
try to search for the definition DIE to just get the name).
I got rough measurement about the time using the same commands (set
breakpoint, run, expr this, exit). For the binary built without
`-gsimple-template-names`, this change has no impact on time, still
taking 41 seconds to complete. When built with
`-gsimple-template-names`, it also takes about 41 seconds to complete
wit this change.



To unsubscribe from these emails, change your notification settings at https://github.com/llvm/llvm-project/settings/notifications