Michael137 wrote:
Huh this is an interesting one. So it looks like we first parse and insert
`struct Inner` into `UniqueDWARFASTTypeMap` as a forward declaration. Then when
we search the debug-map for the definition of `Inner`, we find it declared as
`class Inner` (note, *class* vs. *struct*...i.e., the DIE tags don't match),
and fail to find the entry in said map. So we end up not calling
`StartTagDeclarationDefinition` by the time we get to `CompleteType`, and hence
we assert.
If i hack those to align all is well:
```
(lldb) n
Process 61300 stopped
* thread #1, queue = 'com.apple.main-thread', stop reason = step over
frame #0: 0x00000001204bd8f8
liblldb.19.0.0git.dylib`lldb_private::plugin::dwarf::UniqueDWARFASTTypeList::Find(this=0x0000000107bceb28,
die=0x000000016fdfa428, decl=0x000000016fdf98b0, byte_size=4, is_forward_d
eclaration=false) at UniqueDWARFASTType.cpp:21:9
18 const int32_t byte_size, bool is_forward_declaration) {
19 for (UniqueDWARFASTType &udt : m_collection) {
20 // Make sure the tags match
-> 21 if (udt.m_die.Tag() == die.Tag()) {
22 // If they are not both definition DIEs or both declaration DIEs,
then
23 // don't check for byte size and declaration location, because
declaration
24 // DIEs usually don't have those info.
Target 0: (lldb) stopped.
(lldb) p udt.m_die.Tag()
(dw_tag_t) DW_TAG_structure_type
(lldb) p die.Tag()
(dw_tag_t) DW_TAG_class_type
(lldb) p die.m_die->m_tag = (llvm::dwarf::Tag)0x0013
(dw_tag_t) DW_TAG_structure_type
(lldb) c
Process 61300 resuming
(D::Inner &) inner_d = 0x000000010000400c (j = 68)
(lldb) Process 61300 exited with status = 0 (0x00000000)
```
https://github.com/llvm/llvm-project/pull/92328
_______________________________________________
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
