[all-commits] [llvm/llvm-project] 28d149: [lldb][SymbolFileDWARF] Share GetDIEToType between...

[Michael Buch via All-commits]

  Branch: refs/heads/main
  Home:   https://github.com/llvm/llvm-project
  Commit: 28d14904c00b74154b8dfa71d5b062a7e590c44c
      https://github.com/llvm/llvm-project/commit/28d14904c00b74154b8dfa71d5b062a7e590c44c
  Author: Michael Buch <michaelbuch12 at gmail.com>
  Date:   2024-12-23 (Mon, 23 Dec 2024)

  Changed paths:
    M lldb/source/Plugins/SymbolFile/DWARF/DWARFASTParserClang.cpp
    M lldb/source/Plugins/SymbolFile/DWARF/SymbolFileDWARF.cpp
    M lldb/source/Plugins/SymbolFile/DWARF/SymbolFileDWARF.h
    M lldb/source/Plugins/SymbolFile/DWARF/SymbolFileDWARFDebugMap.h
    M lldb/source/Plugins/SymbolFile/DWARF/SymbolFileDWARFDwo.cpp
    M lldb/source/Plugins/SymbolFile/DWARF/SymbolFileDWARFDwo.h
    A lldb/test/API/lang/cpp/typedef-to-outer-fwd/Makefile
    A lldb/test/API/lang/cpp/typedef-to-outer-fwd/TestTypedefToOuterFwd.py
    A lldb/test/API/lang/cpp/typedef-to-outer-fwd/lib.cpp
    A lldb/test/API/lang/cpp/typedef-to-outer-fwd/lib.h
    A lldb/test/API/lang/cpp/typedef-to-outer-fwd/main.cpp

  Log Message:
  -----------
  [lldb][SymbolFileDWARF] Share GetDIEToType between SymbolFiles of a SymbolFileDWARFDebugMap (#120569)

The problem here manifests as follows:
1. We are stopped in main.o, so the first `ParseTypeFromDWARF` on
`FooImpl<char>` gets called on `main.o`'s SymbolFile. This adds a
mapping from *declaration die* -> `TypeSP` into `main.o`'s
`GetDIEToType` map.
2. We then `CompleteType(FooImpl<char>)`. Depending on the order of
entries in the debug-map, this might call `CompleteType` on `lib.o`'s
SymbolFile. In which case, `GetDIEToType().lookup(decl_die)` will return
a `nullptr`. This is already a bit iffy because some of the surrounding
code assumes we don't call `CompleteTypeFromDWARF` with a `nullptr`
`Type*`. E.g., `CompleteEnumType` blindly dereferences it (though enums
will never encounter this because their definition is fetched in
ParseEnum, unlike for structures).
3. While in `CompleteTypeFromDWARF`, we call `ParseTypeFromDWARF` again.
This will parse the member function `FooImpl::Create` and its return
type which is a typedef to `FooImpl*`. But now we're inside `lib.o`'s
SymbolFile, so we call it on the definition DIE. In step (2) we just
inserted a `nullptr` into `GetDIEToType` for the definition DIE, so we
trivially return a `nullptr` from `ParseTypeFromDWARF`. Instead of
reporting back this parse failure to the user LLDB trucks on and marks
`FooImpl::Ref` to be `void*`.

This test-case will trigger an assert in `TypeSystemClang::VerifyDecl`
even if we just `frame var` (but only in debug-builds). In release
builds where this function is a no-op, we'll create an incorrect Clang
AST node for the `Ref` typedef.

The proposed fix here is to share the `GetDIEToType` map between
SymbolFiles if a debug-map exists.

**Alternatives considered**
* Check the `GetDIEToType` map of the `SymbolFile` that the declaration
DIE belongs to. The assumption here being that if we called
`ParseTypeFromDWARF` on a declaration, the `GetDIEToType` map that the
result was inserted into was the one on that DIE's SymbolFile. This was
the first version of this patch, but that felt like a weaker version
sharing the map. It complicates the code in `CompleteType` and is less
consistent with the other bookkeeping structures we already share
between SymbolFiles
* Return from `SymbolFileDWARF::CompleteType` if there is no type in the
current `GetDIEToType`. Then `SymbolFileDWARFDebugMap::CompleteType`
could continue to the next `SymbolFile` which does own the type. But
that didn't quite work because we remove the
`GetForwardCompilerTypeToDie` entry in `SymbolFile::CompleteType`, which
`SymbolFileDWARFDebugMap::CompleteType` relies upon for iterating



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