ayermolo wrote:
> > Using example above, with a fix by @dwblaikie
> > I see:
> > ```
> > Hash: 0xE0CDC6A2
> > String: 0x00000018 "InnerState"
> > Entry @ 0x10b {
> > Abbrev: 0x3
> > Tag: DW_TAG_class_type
> > DW_IDX_type_unit: 0x01
> > DW_IDX_die_offset: 0x00000030
> > }
> > ```
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> > Since clang no longer emits entry for:
> > ```
> > 0x00000057: DW_TAG_structure_type
> > DW_AT_declaration (true)
> > DW_AT_signature (0xe742f49eeadc2244)
> > ```
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> > Is this the right behavior?
>
> I would say "yes", because the spec is pretty explicit about excluding
> DW_AT_declaration entries.
>
> I can see a case being made that DW_AT_signature should be treated the same
> way as DW_AT_specification and DW_AT_abstract_origin (i.e., transparently),
> but that's definitely not what the spec says right now.
>
> > Current BOLT behavior is to skip that DIE and reference it's parent:
> > ```
> > Hash: 0xE0CDC6A2
> > String: 0x00000018 "InnerState"
> > Entry @ 0x109 {
> > Abbrev: 0x3
> > Tag: DW_TAG_class_type
> > DW_IDX_type_unit: 0x01
> > DW_IDX_die_offset: 0x00000030
> > DW_IDX_parent: Entry @ 0x147
> > }
> > Entry @ 0x147 {
> > Abbrev: 0x7
> > Tag: DW_TAG_namespace
> > DW_IDX_type_unit: 0x01
> > DW_IDX_die_offset: 0x00000025
> > DW_IDX_parent: Entry @ 0x126
> > }
> > ```
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> > ```
> > 0x00000055: DW_TAG_namespace
> > DW_AT_name ("B")
> >
> > 0x00000057: DW_TAG_structure_type
> > DW_AT_declaration (true)
> > DW_AT_signature (0xe742f49eeadc2244)
> >
> > 0x00000060: DW_TAG_class_type
> > DW_AT_calling_convention (DW_CC_pass_by_value)
> > DW_AT_name ("InnerState")
> > DW_AT_byte_size (0x01)
> > DW_AT_decl_file ("/main.cpp")
> > DW_AT_decl_line (1)
> > ```
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> > It doesn't emit entry for this because there is no name attribute
> > ```
> > 0x00000057: DW_TAG_structure_type
> > DW_AT_declaration (true)
> > DW_AT_signature (0xe742f49eeadc2244)
> > ```
>
> This gets a bit fuzzy, I think. The spec appears to allow this behavior (_In
> such a case, a parent attribute may point to a nameless index entry (...), or
> it may point to the **nearest ancestor that does have an index entry**._),
> but I don't think this is particularly useful. I think it would be better to
> have the parent point to the definition in the type unit (streching the
> meaning of "parent" in the spec), or use one of those nameless entries to
> point to the physical (declaration) parent)
>
> (IANAL YMMV)
For "parent point to the definition in the type unit". That definition will be
in a different type unit, correct? Is that allowed? For one entry
DW_IDX_type_unit will have one index, and it's parent will have another index.
There is also DWP scenario. Where we don't know which TU will be picked. So
chain might be pointing to "discarded" TU from a different CU.
So in this particular case what would the nameless entry look like?
https://github.com/llvm/llvm-project/pull/91808
_______________________________________________
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
