[Dwarf-Discuss] debug_names - what should go in ?

David Blaikie dblaikie@gmail.com
Tue Apr 10 15:44:24 GMT 2018


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 at 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 at lists.dwarfstd.org
> http://lists.dwarfstd.org/listinfo.cgi/dwarf-discuss-dwarfstd.org
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.dwarfstd.org/pipermail/dwarf-discuss-dwarfstd.org/attachments/20180410/4d11e5eb/attachment.html>



More information about the Dwarf-discuss mailing list