Michael137 wrote: > > > > 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). > > > > > > > > > Should we bail out early if the Type* is null and return false to tell > > > `SymbolFileDWARFDebugMap::CompleteType` that it can not complete this > > > type and let it iterate to the symbol file that has the entry in its map. > > > > > > Yea that might be even simpler. Let me try that. > > Also, the other crash i alluded to seems to come from the fact that > > `UniqueDWARFASTTypeList::Find` will compare `Declaration`s (i.e., line and > > col info) regardless of whether we're dealing with C++ or not. But > > `GetUniqueTypeNameAndDeclaration` will return a `0` `Declaration` for C++. > > So we can end up inserting the `Declaration` for a definition DIE into the > > map (via `UpdateToDefDIE`), but then try to retrieve it using a `0` > > `Declaration`. Should have a patch up for that soon (I think we can just > > skip the declaration check if we're dealing with C++?) > > I agree that checking `Declaration` for C++ die isn't necessary, the unique > name should be sufficient. I get that Declaration is cleared for all C++ die > in `GetUniqueTypeNameAndDeclaration`, so they all have 0 declaration and > checking on declaration will just always be true for C++ right? How does it > cause a problem?
It's causing issues when we call `ParseTypeFromDWARF` while we're inside `CompleteRecordType`. E.g., in the test-case in this patch. `CompleteRecordType` will call `UpdateToDefDIE`, which will update the `Declaration` stored in the map to something non-zero (we get it from the `ParsedDWARFTypeAttributes(def_die)`). Then if we call `ParseTypeFromDWARF`, we will search the map for a `0` `Declaration` (because of `GetUniqueTypeNameAndDeclaration`). So we don't find the type and create a new forward declaration. Which causes problems later down the line https://github.com/llvm/llvm-project/pull/120569 _______________________________________________ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
