I'd say any case where a consumer couldn't actually rely on the table to do name resolution would be a bug - or at least something that needs to be seriously considered/discussed/figured out how the name table can be used in those situations.
On Tue, Apr 10, 2018 at 8:33 AM Pavel Labath via Dwarf-Discuss < dwarf-discuss@lists.dwarfstd.org> wrote: > Hello dwarf-discuss, > > over the last couple of months, I have been implementing DWARF v5 > debug_names generation support in llvm. Implementation is not yet fully > finished, but I have reached a point where I can start testing the > generated index for completeness. > > I wrote a tool (based on LLVM's DWARF verifier) which goes through the > generated debug info and compares it to the contents of the name index. > Right now it takes any debug info entry with a DW_AT_name, applies the > exclusions listed in section 6.1.1.1 of the specification and then reports > if the entry is not present in the index. > > I chose to start with default-to-in policy for the verifier, so I can > evaluate whether any reported discrepancies for possible inclusion or > blacklisting *and* because the wording at the start of the said section was > a bit indeterminate to me -- it uses somewhat vague terms like "subprogram" > and "variable" (***), whereas the rest of the section speaks about specific > tags (DW_TAG_variable, etc.). > > So far, this approach has found a couple of bugs in the generator, some > things which I obviously needed to blacklist (DW_TAG_compilation_unit), and > a couple of questionable reports. Two of the last kind are > DW_TAG_imported_declaration and DW_TAG_enumerator (not > DW_TAG_enumeration_type). > > Both of these define globally visible entities and so if they were not > present, a debugger relying only on the name index would fail to find the > imported enitity or the enumerator even though they should be visible by > the standard scope rules. And yet, both of these are clearly *not* a "named > subprogram, label, variable, type, or namespace". The extra complication > for DW_TAG_imported_declaration is that it can define a named entity even > when it does not have a DW_AT_name attribute (3.2.3: If no name is present, > then the name by which the entity is to be known is the same as the name of > the entity being imported.). > > I believe it makes sense to include both of these things in the index > (including the implicitly-named imported declarations), however I would > also like to stick to the specification as much as possible. I know the > spec gives implementors freedom to include extra information in the index, > but I don't want to do that too much, as that would complicate matters for > consumers which need to support multiple producers, some of which may have > a stricter implementation of the spec. > > So, I wanted to hear your thoughts on this first. How strictly should we > interpret the first paragraph of section 6.1.1.1 (***)? Do you think it > makes sense to add these entries to the name index? > > regards, > pavel labath > > > (***) ""The name index must contain an entry for each debugging information > entry that defines a named subprogram, label, variable, type, or namespace, > subject to the following rules:"" > _______________________________________________ > Dwarf-Discuss mailing list > Dwarf-Discuss@lists.dwarfstd.org > http://lists.dwarfstd.org/listinfo.cgi/dwarf-discuss-dwarfstd.org >
_______________________________________________ Dwarf-Discuss mailing list Dwarf-Discuss@lists.dwarfstd.org http://lists.dwarfstd.org/listinfo.cgi/dwarf-discuss-dwarfstd.org
